R: R: [PATCH] R: R: [vdr] VDR Multiple frontends
So what do you think should be the right way? Best Regards Edddi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 8.27 A: vdr@linuxtv.org Oggetto: Re: R: [PATCH] R: R: [vdr] VDR Multiple frontends Eddi wrote: I need help This is why sometimes hangs after my patch... On ProvidesChannel I delete the cDvbDevice and i make it again. Deleting the cDvbDevice is definitely the wrong way to do this. Klaus ___ 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
[vdr] Re: FF card AV sync problems, possible fix to VDR (fwd)
Hi, I have looked into this further. It appears that I only get the TS continuity errors when using my budget DVB-T card to view live TV.. They do not appear when using my FF DVB-S card. Does this shed any light on things? The DVB-T stream is less robust that DVB-S, but the picture does not generally break up regularly or appear to suffer any major problems. Could it be a problem with my Hauppauge budget DVB-T card? SWITCH TO SATELLITE CHANNEL: - Feb 9 10:42:08 morfsta vdr: [25446] switching to channel 166 Feb 9 10:42:08 morfsta vdr: [25446] retuning due to modification of channel 166 Feb 9 10:42:08 morfsta vdr: [25446] switching to channel 166 Feb 9 10:44:47 morfsta vdr: [25446] cleaning up schedules data Feb 9 10:45:00 morfsta vdr: [25540] EPGSearch: timer conflict check started Feb 9 10:45:00 morfsta vdr: [25540] EPGSearch: timer conflict check finished Feb 9 10:51:01 morfsta vdr: [25536] channel 27 (CBeebies) event Fri 09.02.2007 10:50-11:00 'Boo!' status 4 Feb 9 11:02:12 morfsta vdr: [25536] channel 27 (CBeebies) event Fri 09.02.2007 11:00-11:15 'SMarteenies' status 4 Feb 9 11:09:19 morfsta vdr: [25446] cleaning up id3 cache Feb 9 11:15:00 morfsta vdr: [25540] EPGSearch: timer conflict check started Feb 9 11:15:00 morfsta vdr: [25540] EPGSearch: timer conflict check finished Feb 9 11:17:32 morfsta vdr: [25536] channel 27 (CBeebies) event Fri 09.02.2007 11:15-11:45 'Teletubbies' status 4 SWITCH TO FREEVIEW DVB-T CHANNEL: - Feb 9 11:35:55 morfsta vdr: [25446] switching to channel 1 Feb 9 11:35:57 morfsta vdr: [25536] channel 2 (BBC TWO) event Fri 09.02.2007 11:20-11:40 'Schools: Focus' status 4 Feb 9 11:35:57 morfsta vdr: [25536] channel 1 (BBC ONE) event Fri 09.02.2007 11:00-11:45 'To Buy or Not to Buy' status 4 Feb 9 11:38:12 morfsta vdr: [12243] TS continuity error (15) Feb 9 11:38:12 morfsta vdr: [12243] TS continuity error (1) Feb 9 11:38:12 morfsta vdr: [12243] TS continuity error (9) I generally only get sync problems on live DVB-T broadcasts (as well as all recordings). Hope this helps, Regards, Morfsta On 2/5/07, Morfsta [EMAIL PROTECTED] wrote: Reinhard, Thanks for your help and description. Can anyone help me track down what might be the problem? I built my own kernel could a setting there be a problem? What settings are recommended for type of IO scheduler, timer frequency, etc? Anyone else have a similar problem and can recommend a fix? Cheers, Morfsta On 2/5/07, Reinhard Nissl [EMAIL PROTECTED] wrote: Hi, Morfsta wrote: Lots of TS Continuity Errors in the messages file. Feb 5 08:25:00 morfsta vdr: [19772] TS continuity error (11) Feb 5 08:25:01 morfsta vdr: [19772] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame Sad to say, I'm happy that this is not a bug in cAudioRepacker. So what can you do about this TS continuity errors? First of all, this error means that at least one TS packet got lost, most likely by the fact that the card's hardware buffers where overrun. A overrun can happen when for example the kernel is busy with other things and doesn't react to the cards signalling (e. g. IRQ) in time. Several months ago, I had my PATA harddrive sent in for repair and substituted it by a SATA model. The result was, that I wasn't able to take a single VDR recording on my P4 2.8 GHz without TS continuity errors. When I got the PATA drive back and removed the SATA model, the TS errors were gone. So I'd say this is a hardware/driver/configuration issue -- but not necessarily in the DVB area. I hope, someone else can give you further hints. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ 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
[vdr] ts continuity error
Hello, My problem was not the audiorepackager(xxx). I found some threads about these error in vdr-portal and modified vdr to get some more debug output. There were a lot of ts continuity errors reported through syslog. My machine has a athlon xp 1500 cpu and runs on a asrock mainboard with sis chipset. The errors are shown after recording some minutes on all channels. I tested to record over nfs to check the harddisk but that did not help. I tried it with vdr-1.4.5 without any plugins and patches etc. Now I have no ideas what I can try. The caudiorepackager errors are perhaps a result of dropped bytes before??? My card is a ff dvb-s 2.3 from technotrend. I do not currently use a cam. Last test-firmware and different drivers tested with no success. ((Please help) Best regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: video data stream broken on second dvb card , but szap works (include recording)
Hi, with strace I can see, that vdr tries to open video0 and audio0, which aren't there. Do they have to exist for nova cards ? video:/var/service/vdr # grep adapter1 /tmp/vdr-1.5.0.strace access(/dev/dvb/adapter1/frontend0, F_OK) = 0 open(/dev/dvb/adapter1/frontend0, O_RDONLY) = 10 open(/dev/dvb/adapter1/frontend0, O_RDWR|O_NONBLOCK) = 10 open(/dev/dvb/adapter1/osd0, O_RDWR) = -1 ENOENT (No such file or directory) open(/dev/dvb/adapter1/video0, O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory) open(/dev/dvb/adapter1/audio0, O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory) open(/dev/dvb/adapter1/demux0, O_RDWR) = 11 open(/dev/dvb/adapter1/ca0, O_RDWR) = -1 ENOENT (No such file or directory) open(/dev/dvb/adapter1/demux0, O_RDWR|O_NONBLOCK) = 26 open(/dev/dvb/adapter1/demux0, O_RDWR|O_NONBLOCK) = 27 open(/dev/dvb/adapter1/demux0, O_RDWR|O_NONBLOCK) = 28 video:/var/service/vdr # On Fri, Feb 09, Dieter Bloms wrote: Hi, I have two cards in my video server: Technotrend/Hauppauge WinTV Nexus-S rev2.3) Hauppauge Nova-S-Plus DVB-S [card=37] lspci: 01:0c.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 01:0c.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) 01:0c.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) 01:0c.4 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05) 01:0f.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) when I use szap to change the channel, I can switch, record, switch, record (record with cat /dev/dvb/adapter1/dvr0 /tmp/tsvideo. But when I try to record with vdr, I get the following errors and nothing will be record: (with plain vdr-1.5.0 and plain vdr-1.4.0 and v4l-dvb from yesterdays hg): Feb 9 12:02:00 video vdr: [30529] connect from 127.0.0.1, port 60607 - accepted Feb 9 12:02:00 video vdr: [30529] timer 10 (1 1200-1215 VPS 'Tagesschau um zwölf') added Feb 9 12:02:00 video vdr: [30529] closing SVDRP connection Feb 9 12:02:00 video vdr: [30529] switching device 2 to channel 1 Feb 9 12:02:00 video vdr: [30529] timer 10 (1 1200-1215 VPS 'Tagesschau um zwölf') start Feb 9 12:02:00 video vdr: [30529] Title: 'Tagesschau um zwölf' Subtitle: '' Feb 9 12:02:00 video vdr: [30529] record /data/nobackup/video/Tagesschau_um_zwölf/2007-02-09.12.00.50.50.rec Feb 9 12:02:00 video vdr: [30529] creating directory /data/nobackup/video/Tagesschau_um_zwölf Feb 9 12:02:01 video vdr: [30529] creating directory /data/nobackup/video/Tagesschau_um_zwölf/2007-02-09.12.00.50.50.rec Feb 9 12:02:01 video vdr: [30529] recording to '/data/nobackup/video/Tagesschau_um_zwölf/2007-02-09.12.00.50.50.rec/001.vdr' Feb 9 12:02:01 video vdr: [30529] connect from 127.0.0.1, port 60610 - accepted Feb 9 12:02:01 video vdr: [30529] closing SVDRP connection Feb 9 12:02:01 video vdr: [30603] file writer thread started (pid=30529, tid=30603) Feb 9 12:02:01 video vdr: [30604] recording thread started (pid=30529, tid=30604) Feb 9 12:02:01 video vdr: [30605] receiver on device 2 thread started (pid=30529, tid=30605) Feb 9 12:02:01 video vdr: [30606] TS buffer on device 2 thread started (pid=30529, tid=30606) Feb 9 12:02:03 video vdr: [30529] timer 10 (1 1200-1215 VPS 'Tagesschau um zwölf') set to event Fre 09.02.2007 12:00-12:15 (VPS: 09.02 12: 00) 'Tagesschau um zwölf' Feb 9 12:02:09 video vdr: [30537] frontend 1 timed out while tuning to channel 1, tp 111836 Feb 9 12:02:10 video vdr: [30529] connect from 127.0.0.1, port 60614 - accepted Feb 9 12:02:10 video vdr: [30529] closing SVDRP connection Feb 9 12:02:10 video vdr: [30529] connect from 127.0.0.1, port 60617 - accepted Feb 9 12:02:10 video vdr: [30529] closing SVDRP connection Feb 9 12:02:27 video vdr: [30529] connect from 127.0.0.1, port 60622 - accepted Feb 9 12:02:27 video vdr: [30529] closing SVDRP connection Feb 9 12:02:32 video vdr: [30603] ERROR: video data stream broken Feb 9 12:02:32 video vdr: [30603] initiating emergency exit Feb 9 12:02:32 video vdr: [30529] emergency exit requested - shutting down Feb 9 12:02:32 video vdr: [30604] recording thread ended (pid=30529, tid=30604) Feb 9 12:02:32 video vdr: [30603] file writer thread ended (pid=30529, tid=30603) Feb 9 12:02:32 video vdr: [30529] buffer stats: 0 (0%) used Feb 9 12:02:32 video vdr: [30529] timer 10 (1 1200-1215 VPS 'Tagesschau um zwölf') stop Feb 9 12:02:32 video vdr: [30529] saved setup to /etc/vdr/setup.conf Feb 9 12:02:32 video vdr: [30534] tuner on device 1 thread ended (pid=30529, tid=30534) Feb 9 12:02:33 video vdr: [30606] TS buffer on device 2 thread ended (pid=30529, tid=30606) Feb 9 12:02:33 video vdr: [30605] buffer stats: 0 (0%) used Feb 9 12:02:33 video vdr: [30605] receiver on device 2 thread ended (pid=30529,
Re: [PATCH]: [vdr] VDR Multiple frontends
Eddi wrote: So what do you think should be the right way? I haven't decided yet how to do that. I just wanted to let you know that deleting the cDvbDevice is not the way to go - especially if you delete it from within one of its own member functions ;-) It's no wonder your patched version fails it you saw off the branch you're sitting on. Klaus -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 8.27 A: vdr@linuxtv.org Oggetto: Re: R: [PATCH] R: R: [vdr] VDR Multiple frontends Eddi wrote: I need help This is why sometimes hangs after my patch... On ProvidesChannel I delete the cDvbDevice and i make it again. Deleting the cDvbDevice is definitely the wrong way to do this. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
Zitat von Reinhard Nissl [EMAIL PROTECTED]: Hi, Thomas Lagemann wrote: Just another thought about the timing: MPEG-2 defines rules for a system target decoder, thats in charge for decoding and presenting the media at the right time, using the PTS-stamps in the PES packets. Is this usually done by the driver or is there a VDR instance that deals with this. It's done in the driver / xine. But it shouldn't be to complicated to extract the PTS value from a TS packet. The PTS value is very near to the beginning of a PES packet and a bit in the TS packet tells you that a new PES packet starts in this TS packet. When you extract PTS for each PID and calculate the difference to the first seen PTS for each PID, then you evaluate, how much time should have passed since the beginning of the TS file. If you put this information in relation to the time passed in reality since opening the TS file, you can throttle the TS stream so that it doesn't overflow the buffers any more. BTW: keep in mind, that video PTS jump back and forth as the images are broadcast in decoding order while the PTS time stamps describe presentation order. This works perfekt! Thank you very much, for the idea :-) Regards, Thomas This message was sent using IMP, the Internet Messaging Program. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
R: [PATCH]: [vdr] VDR Multiple frontends
Ok, I hope that what I have done, may describe the algorithm that I think may be necessary to get multiple frontend working. I know that the solution I choose are not the best and right, I'm not a c++ programmer! The only solution I found to close all file descriptors and /dev/dvb/adapter0/frontend0 was to add the close fd_frontend to the dvb device destructor. Eddi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 13.43 A: vdr@linuxtv.org Oggetto: Re: [PATCH]: [vdr] VDR Multiple frontends Eddi wrote: So what do you think should be the right way? I haven't decided yet how to do that. I just wanted to let you know that deleting the cDvbDevice is not the way to go - especially if you delete it from within one of its own member functions ;-) It's no wonder your patched version fails it you saw off the branch you're sitting on. Klaus -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Klaus Schmidinger Inviato: venerdì 9 febbraio 2007 8.27 A: vdr@linuxtv.org Oggetto: Re: R: [PATCH] R: R: [vdr] VDR Multiple frontends Eddi wrote: I need help This is why sometimes hangs after my patch... On ProvidesChannel I delete the cDvbDevice and i make it again. Deleting the cDvbDevice is definitely the wrong way to do this. Klaus ___ 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
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
I demand that VDR User may or may not have written... [snip] Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways. They might point a camera (probably a webcam) at it, though... [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output less CO2 = avoid boiling weather. TIME IS RUNNING OUT *FAST*. You humans are all alike. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
On Fri, Feb 09, 2007 at 05:55:54PM +, Darren Salt wrote: I demand that VDR User may or may not have written... [snip] Also, a coffee-maker is not a device used for entertainment purposes. Nobody turns their coffee-maker on and then sits there watching it. I hope not anyways. They might point a camera (probably a webcam) at it, though... Such as the original webcam? http://www.theregister.co.uk/2001/03/07/worlds_first_webcam_coffee_pot/ Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
