[vdr] mhwepg
Anyone else getting seg faults on this for Sky Italia? -- Latest news on http://www.streetcredo.org.uk/rob Rob Davis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mhwepg
En/na Rob Davis ha escrit: Anyone else getting seg faults on this for Sky Italia? raise MAX_CHANNELS to 400 and MAX_PROGRAMS to 35000 (or, alternatively, find a way to only get the epg for fta channels, avoiding all the useless crap I cannot view anyway). The transponder with the epg is now at 11355. Oh, and run mhwepg with the -l option Bye. -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] prevernting vdr restart on bad signal?
Ali H.M. Hoseini wrote: hi all, I've noticed that when the signal quality goes low ( high BER or high UNC), and if a timer records that channel simultaneously, the vdr exits continuously, and hence produces too many recording files. How should I prevent vdr from exit, in this situations? Locate the line cThread::EmergencyExit(true); in recorder.c and comment it out. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] prevernting vdr restart on bad signal?
Klaus Schmidinger schrieb: Ali H.M. Hoseini wrote: hi all, I've noticed that when the signal quality goes low ( high BER or high UNC), and if a timer records that channel simultaneously, the vdr exits continuously, and hence produces too many recording files. How should I prevent vdr from exit, in this situations? Locate the line cThread::EmergencyExit(true); in recorder.c and comment it out. Hi Klaus! I think the dvb-drivers is quite stable now. At least on my VDR there are almost no problems with the stability. So I think there are maybe zwo big issues left (I dont' know for sure) which can be solved by a restart of the drivers (and VDR): - the good old uknown picture type-error - the video data stream broken-error Is it possible to distinguish between these errors and a reception-error due to bad signal-quality (snow on the dish, very bad weather ...)? If there is a way to distinguish between this errors would it be possible to make the emergency exit only if it can fix the problem? On systems with more cards/dishes it could also help to check if there is a ongoning recording wich has no problems (for example card 1 records on one dish with good reception and card 2 tries to start a recording on a dish with bad reception). Maybe if there are working ongoing recordings the start of an additional recording which doesn't work should not restart VDR as it interrupts the working recordings? So maybe a preferd behaviour of VDR could be: upt or vdsb-error -- EmergencyExit if there is no working recording; do nothing otherwise errors which can be lead back to reception-issues -- do nothing What do you think? Bye, Andreas Brugger ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mhwepg
Luca Olivetti wrote: En/na Rob Davis ha escrit: Anyone else getting seg faults on this for Sky Italia? raise MAX_CHANNELS to 400 and MAX_PROGRAMS to 35000 (or, alternatively, find a way to only get the epg for fta channels, avoiding all the useless crap I cannot view anyway). The transponder with the epg is now at 11355. Oh, and run mhwepg with the -l option I have a sky italia sub, so having everything is useful. Is Max_Channels and Max_Programs in the source? -- Latest news on http://www.streetcredo.org.uk/rob Rob Davis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR version 1.4.5 released
VDR version 1.4.5 is now available at ftp://ftp.cadsoft.de/vdr/vdr-1.4.5.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.4-1.4.5.diff A 'diff' against the latest maintenance patch is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.4-3-1.4.5.diff A summary of all the major changes since the last stable version can be found at http://www.cadsoft.de/vdr/download.htm This version is source compatible with the previous version, so plugins only need to be recompiled. Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR. Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.5.0
VDR developer version 1.5.0 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.0.tar.bz2 A 'diff' against the latest stable version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-1.5.0.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version focuses mainly on improvements in CAM handling. The highlights are: - Improved CAM menu and reset handling. - Automatic selection of suitable CAM in a system with several CAMs that claim to decrypt a given channel. - Decrypting of several channels on the same transponder (if the CAM is able to do this). The changes since version 1.4.5: - The CAM handling has been refactored. Instead of a cCiHandler per device there is now an abstract cCiAdapter and a cCamSlot. This allows each slot to be accessed individually. - The general 15 seconds workaround time before opening the CAM menu has been removed. If the CAM menu doesn't open within a timeout, the enter menu command is now sent again. - If a CAM is reset or pulled and reinserted, it now automatically starts decrypting the current channel again. - The Setup/CAM menu now dynamically refreshes its items and displays whether a CAM is present or ready. The 'Reset' function no longer leaves the menu. - The CAM menu will now be openend when pressing the Ok key on a slot entry. - The CAM menu now stays within the current menu context and doesn't close and reopen the menu every time an option is selected. - When an encrypted channel is switched to for the first time, VDR now checks explicitly whether a CAM can actually decrypt that channel. If there is more than one CAM in the system that claims to be able to decrypt the channel, they are all tried in turn. To make this possible, an encrypted channel needs to be received in Transfer Mode when it is switched to for the first time, so that VDR can determine whether the TS packets are actually decrypted. Once a channel is known to be decrypted by a particular CAM, the next time it is switched to it will be shown in normal live viewing mode. - A cDevice now automatically detaches all cReceiver objects that receive PIDs that can't be decrypted with the current CAM. A plugin that attaches a cReceiver to a device should therefore watch the receiver's IsAttached() function to see if it is still attached to the device. - The cReceiver constructor no longer takes an 'int Ca' as its first parameter, but rather a 'tChannelID ChannelID'. This is necessary for the device to be able to determine which CAM a particular channel can be decrypted with. If the channel is known to be unencrypted, or a plugin doesn't want to provide the channel id for other reasons, an invalid tChannelID() can be given. - The cThread::Start() function now waits until a previous incarnation of this thread has actually stopped. Before this it could happen that a thread's Cancel(-1) function was called and immediately after that it was started again, but the Start() function still found it to be 'active'. - The parameter NeedsDetachReceivers in cDevice::GetDevice(const cChannel *Channel, ...) has been removed. A call to this function will automatically detach all receivers from the device if it returns a non-NULL pointer. - The cTimeMs class now accepts an initial timeout value in its constructor. - A CAM is now explicitly instructed to stop decrypting when switching away from an encrypted channel. - If the CAM in use can decrypt several channels at the same time, VDR can now make use if this capability. Whether or not a CAM can decrypt more than one channel is determined by sending it an initial empty QUERY command and testing whether it replies to it. - Ca values in the range 0...F in channels.conf can still be used to assign a channel to a particular device, but this will no longer work with encrypted channels because without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now automatically determines which CAM can decrypt which channel, setting fixed channel/device relations should no longer be necessary. KNOWN BUG - PLEASE HELP DEBUGGING: Start VDR with only one FF DVB card and an attached CI with a CAM. Switch to an encrypted channel for the first time, the channel is shown in Transfer Mode. Wait for at least 10 seconds, so that VDR will mark the CAM as able to decrypt this channel. Now switch to the same channel again (by selecting it from the Channels menu or typing in its number), and the screen goes black. VDR is now receiving the channel in normal live mode (no Transfer Mode). Apparently there is a problem with switching to live mode after using Transfer Mode. The problem goes away if you switch to a channel on a different transponder and then back to the original one. Now it is shown even in
Re: [vdr] missing dvb subtitles in records
2007/1/7, Arthur Konovalov [EMAIL PROTECTED]: Hi. I noticed that dvb subtitles not recorded with video. Can anyone confirm that it works? Hi, I have a similar setup and yes, DVB subtitles are recorded. I don't use ttxtsubs at all (only the DVB ones). However, I have noticed that recently, on some recordings, there are long pauses for subtitles (1-5 minutes, haven't taken time actually) and then suddenly all (?) subtitles that should have been shown previously are shown for about 0.1s each, and then subtitles resume normally. More specifically, I had this problem with Cold Lazarus series that I recorded from YLE Teema on 28.12.2006, and possibly with some others IIRC. But it doesn't bother me much, so I didn't note which recording it was. This is similar to the behavior I have always got when I jump in a recording with dvb subtitles, but then the pause is usually ~30s, max. 1 minute. It is as if the subtitles are in blocks and displaying them can only resume at the end/start of a block. My environment: Slackware-11.0, kernel 1.6.19, vdr-1.4.4-3 with vdr-1.4.4-liemikuutio-1.13.diff, vdr-1.4.4-subtitles-0.4.0-and-ttxtsubs-0.0.5.diff I have : - Gentoo - kernel 2.6.19 - probably you too ;) - VDR 1.4.4_p2 - skinelchi - subtitles-0.4.0 - (and ttxtsubs-0.0.5_p2, but I don't use them) - loads of other plugin, for example dxr3 ProjectX demux not detect dvb subtitles too. I have never tried projectX or any other means to convert the recordings made by VDR to other formats. But I'd guess this could be a ProjectX issue, but if VDR can't replay subtitles from your recording, then theres something wrong with your setup (a missing patch or something). I strongly recommend using Gentoo for VDR. -- Ville Aakko - [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mhwepg
Luca Olivetti wrote: En/na Rob Davis ha escrit: Anyone else getting seg faults on this for Sky Italia? raise MAX_CHANNELS to 400 and MAX_PROGRAMS to 35000 (or, alternatively, find a way to only get the epg for fta channels, avoiding all the useless crap I cannot view anyway). The transponder with the epg is now at 11355. Oh, and run mhwepg with the -l option Bye. Ok, found it, and successfully downloaded everything. -- Latest news on http://www.streetcredo.org.uk/rob Rob Davis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mplayer plugin - no sound on vdr-1.4.4 ?
On Fri, 05 Jan 2007 23:23:54 +, VDR User wrote: Works fine here. I'd suggest you double-check your settings and make sure something didn't get messed up somewhere. you were right, I messed up, as I was still using 0.9.15-pre10 :/ It is working fine with 0.9.15. Soeren ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New UTF-8 patch is now available.
On Sun, Jan 07, 2007 at 10:47:08PM +0200, Marko Mäkelä wrote: Do you have a script for translating the /video directory from latin1 to utf8? I attach my script for this, also available from http://www.iki.fi/~msmakela/software/misc/. Sorry, the script only works well when no directories need to be renamed. Something more advanced is needed, perhaps invoking GNU find -maxdepth in a loop. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.0
Klaus Schmidinger wrote: VDR developer version 1.5.0 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.0.tar.bz2 A 'diff' against the latest stable version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-1.5.0.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. This version focuses mainly on improvements in CAM handling. The highlights are: - Improved CAM menu and reset handling. - Automatic selection of suitable CAM in a system with several CAMs that claim to decrypt a given channel. - Decrypting of several channels on the same transponder (if the CAM is able to do this). The changes since version 1.4.5: - The CAM handling has been refactored. Instead of a cCiHandler per device there is now an abstract cCiAdapter and a cCamSlot. This allows each slot to be accessed individually. - The general 15 seconds workaround time before opening the CAM menu has been removed. If the CAM menu doesn't open within a timeout, the enter menu command is now sent again. - If a CAM is reset or pulled and reinserted, it now automatically starts decrypting the current channel again. - The Setup/CAM menu now dynamically refreshes its items and displays whether a CAM is present or ready. The 'Reset' function no longer leaves the menu. - The CAM menu will now be openend when pressing the Ok key on a slot entry. - The CAM menu now stays within the current menu context and doesn't close and reopen the menu every time an option is selected. - When an encrypted channel is switched to for the first time, VDR now checks explicitly whether a CAM can actually decrypt that channel. If there is more than one CAM in the system that claims to be able to decrypt the channel, they are all tried in turn. To make this possible, an encrypted channel needs to be received in Transfer Mode when it is switched to for the first time, so that VDR can determine whether the TS packets are actually decrypted. Once a channel is known to be decrypted by a particular CAM, the next time it is switched to it will be shown in normal live viewing mode. - A cDevice now automatically detaches all cReceiver objects that receive PIDs that can't be decrypted with the current CAM. A plugin that attaches a cReceiver to a device should therefore watch the receiver's IsAttached() function to see if it is still attached to the device. - The cReceiver constructor no longer takes an 'int Ca' as its first parameter, but rather a 'tChannelID ChannelID'. This is necessary for the device to be able to determine which CAM a particular channel can be decrypted with. If the channel is known to be unencrypted, or a plugin doesn't want to provide the channel id for other reasons, an invalid tChannelID() can be given. - The cThread::Start() function now waits until a previous incarnation of this thread has actually stopped. Before this it could happen that a thread's Cancel(-1) function was called and immediately after that it was started again, but the Start() function still found it to be 'active'. - The parameter NeedsDetachReceivers in cDevice::GetDevice(const cChannel *Channel, ...) has been removed. A call to this function will automatically detach all receivers from the device if it returns a non-NULL pointer. - The cTimeMs class now accepts an initial timeout value in its constructor. - A CAM is now explicitly instructed to stop decrypting when switching away from an encrypted channel. - If the CAM in use can decrypt several channels at the same time, VDR can now make use if this capability. Whether or not a CAM can decrypt more than one channel is determined by sending it an initial empty QUERY command and testing whether it replies to it. - Ca values in the range 0...F in channels.conf can still be used to assign a channel to a particular device, but this will no longer work with encrypted channels because without valid CA ids VDR can't decide which CAM slot to use. However, since VDR now automatically determines which CAM can decrypt which channel, setting fixed channel/device relations should no longer be necessary. KNOWN BUG - PLEASE HELP DEBUGGING: Start VDR with only one FF DVB card and an attached CI with a CAM. Switch to an encrypted channel for the first time, the channel is shown in Transfer Mode. Wait for at least 10 seconds, so that VDR will mark the CAM as able to decrypt this channel. Now switch to the same channel again (by selecting it from the Channels menu or typing in its number), and the screen goes black. VDR is now receiving the channel in normal live mode (no Transfer Mode). Apparently there is a problem with switching to live mode after using Transfer Mode. The problem goes away if you switch to a channel on a different transponder and then back to the original one.
Re: [vdr] VDRAdmin-AM-3.5.2: Autotimer missing
Hi, On Saturday 06 January 2007 19:58, Pasi Juppo wrote: Hi, Thanks! This brought Auto timer -menu available. Seems that I need to check epgsearch-plugin as this function will be removed from VDRAdmin-AM. What is the reason why this function gets removed? 1) I don't use AutoTimer, so it's not tested very much by me. 2) IMHO epgsearch is much better and has also the features which have been requested by lots of VDRAdmin-AM users. 3) epgsearch can also be controlled via VDR's OSD. Regards, Andreas Br, Pasi Andreas Mair wrote: Hi, you can also set AT_OFFER=2 in vdradmind.conf. Regards, Andreas On Monday 01 January 2007 22:41, Ville Skyttä wrote: On Monday 01 January 2007 23:14, Pasi Juppo wrote: Upgraded to the most recent version of VDRAdmin (previous was 3.4.5a). Now AutoTimer menu item is missing and can't get it visible. There seems to be option for this (at least vdradmind.pl has reference to it) but does not matter if I change the status in vdradmind.pl or vdradmind.conf file (AUTOTIMER is missing from conf file - if it even should be there). How can I fix the problem? Try removing AT_OFFER from vdradmind.conf and changing -s $AT_FILENAME to -f $AT_FILENAME around line 3000 in vdradmind.pl. Note also that the builtin autotimer functionality is deprecated in favour of using epgsearch, see HISTORY entries from 3.5.0beta onwards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- http://andreas.vdr-developer.org --- VDRAdmin-AM VDR user #303 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
