Re: [vdr] remote control not responding when message is being displayed
[EMAIL PROTECTED] schrieb: Hi, I have a server with an ISDN card and I set it up, so it will send a message via svdrpsend.pl to my VDR Box, when there is an incoming phone call. (http://www.vdr-wiki.de/wiki/index.php/Svdrp-isdnanruf) I am running VDR 1.4.5 on my VDR box. The only thing that is bugging me a bit, is the fact, that my VDR is not responding to any LIRC input as long as the message is being displayed. So it depends on the right timing to pause a running replay. Since the message is repeated every 4 seconds I have to hit the pause key on the remote at the right moment(when there is no message being displayed) to make the replay pause. Can anyone tell me on how to change this behavior? Any other suggestion on how to display the phone number if the ISDN card is not built into the VDR system itself would be appreciated as well. Sounds strange. But apart from that maybe osdserver-plugin might be the better option to display messages as it doesn't seem to rely on svdrp ? Haven't tried that yet, but seems to be very interesting plugin. Kind Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] df_xine and Xine-Plugin
Hi, in a previous post, someone here gave me the tip to use df_xine with DirectFB. That works pretty good, beside the osd behaviour. There is no problem when looking normal television on my 4:3 german tv. But when I switch to a channel with a movie in 16:9, the OSD gets squeezed together and it is a pain to read it. I saw the options in the plugin setup, but I don't believe that this behaviour is normal!? When I start df_xine with -a 4:3, the 16:9 movie ist shown in 4:3 fullscreen mode on my tv (picture gets streched) that also does not look good. I saw posts on this mailing lists from people who start df_xine with -a 5:4, don't 16:9 movies look streched that way? The OSD always uses fullscreen this way, that's the positive thing. Thanks for any advice. regards ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4 - Finnish i18n
Marko Mäkelä wrote: On Tue, Feb 20, 2007 at 08:52:20AM +0200, Rolf Ahrenberg wrote: On Mon, 19 Feb 2007, Udo Richter wrote: Rolf Ahrenberg wrote: I've one question about this sentence: Plugin %s wakes up in %ld min, continue? If I'm pressing 'OK' here, does it continue the shutdown or running the VDR? I don't like it either, but didn't come up with a good other idea for this. For consistency it should be Plugin %s wakes up in %ld minutes, restart anyway?, but thats way too long to fit into the status bar. The alternative would be to drop the plugin name again. My vote goes to dropping the plugin name as it doesn't provide (imho) any valuable information for the user. Do we really need to know that a femon or relay plugin is about to wakeup in ten minutes, when we are restarting the VDR? I'd say: no. Well, then the name of the plugin should be written to the log, for troubleshooting. Or is it necessary to say Plugin %s wakes up? Would it be enough to say %s wakes up? I'd guess that many plugin names are shorter than the translation of Plugin in many languages. Hmm, many languages don't seem to translate the word Plugin, but the Estonian and Finnish translations are among the longest ones. It's better to see which plugin is wanting to prevent the operation than simply something is preventing. The word 'Plugin' on the other hand is unnecessary, IMO. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
On 2/19/07, Kartsa [EMAIL PROTECTED] wrote: I was about to test the performance of vdr when I stumbled on this message ERROR: /dev/dvb/adapter0/demux0: Too many open files I'm also having this error, only in my case, is not only related to recording, it also happens sometimes when just changing the channel: Feb 20 11:02:11 hera vdr: [1027] switching to channel 4 Feb 20 11:02:11 hera vdr: [2812] transfer thread ended (pid=1027, tid=2812) Feb 20 11:02:11 hera vdr: [2814] TS buffer on device 1 thread ended (pid=1027, tid=2814) Feb 20 11:02:11 hera vdr: [2813] buffer stats: 53204 (2%) used Feb 20 11:02:11 hera vdr: [2813] receiver on device 1 thread ended (pid=1027, tid=2813) Feb 20 11:02:11 hera vdr: [1027] buffer stats: 53580 (2%) used Feb 20 11:02:11 hera vdr: [1027] ERROR: can't open filter handle on '/dev/dvb/adapter0/demux0' Feb 20 11:02:11 hera vdr: [1027] ERROR: /dev/dvb/adapter0/demux0: Too many open files Feb 20 11:02:11 hera vdr: [1027] ERROR (dvbdevice.c,687): Too many open files Feb 20 11:02:11 hera vdr: [1027] ERROR: can't set PID 4386 on device 1 Feb 20 11:02:11 hera vdr: [1027] ERROR (dvbdevice.c,712): Bad file descriptor Feb 20 11:02:11 hera vdr: [2821] transfer thread started (pid=1027, tid=2821) When this happens, I have to keep changing channels until I get a lock and it is completly aleatory, to reproduce this error, I have to make several channel switching until it happens. My systems specs: Ubuntu Edgy, kernel 2.6.17(the one that comes with the distro), I'm also using the dvb driver that come with the distro kernels. vdr-1.4.4, the one pre-patched be hooch(www.hoochvdr.info). regards -- Carlos Javier Habana, CUBA ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4 - Finnish i18n
On 2/20/07, Marko Mäkelä [EMAIL PROTECTED] wrote: Would it be enough to say %s wakes up? That's fine if you don't mind using poor grammar. For example, femon wakes up? makes absolutely no sense. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
Carlos Javier Borroto wrote: On 2/19/07, Kartsa [EMAIL PROTECTED] wrote: I was about to test the performance of vdr when I stumbled on this message ERROR: /dev/dvb/adapter0/demux0: Too many open files I'm also having this error, only in my case, is not only related to recording, it also happens sometimes when just changing the channel: What hardware are you using? I mean, what driver is being used? Is it dvb-usb-dtt200u ? If so.. 'me too' :) http://www.linuxtv.org/pipermail/vdr/2006-June/009718.html I never found a solution, so bought different hardware :) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
On 2/20/07, Gavin Hamill [EMAIL PROTECTED] wrote: What hardware are you using? I mean, what driver is being used? Is it dvb-usb-dtt200u ? If so.. 'me too' :) I forget that, I'm using a Nexus card, this is my lspci output: 00:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) And dmesg: ... [17307906.312000] saa7146: found saa7146 @ mem cec7c000 (revision 1, irq 209) (0x13c2,0x0003). [17307906.592000] DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X). [17307906.92] dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f22623 [17307906.92] dvb-ttpci: firmware @ card 0 supports CI link layer interface ... I also forget to say that I'm using xine plugin for output, I don't know is that has something to do, my nexus has the video output broken. http://www.linuxtv.org/pipermail/vdr/2006-June/009718.html Is funny, these mails were the only results google gave me, when I did a search a few days ago. On my systems the limits are: $ grep . /proc/sys/fs/file-* /proc/sys/fs/file-max:21190 /proc/sys/fs/file-nr:4320 0 21190 I never found a solution, so bought different hardware :) To bad, I can't do the same. thanks -- Carlos Javier Habana, CUBA ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
Kartsa kirjoitti: Carlos Javier Borroto kirjoitti: On 2/20/07, Gavin Hamill [EMAIL PROTECTED] wrote: What hardware are you using? I mean, what driver is being used? Is it dvb-usb-dtt200u ? If so.. 'me too' :) I forget that, I'm using a Nexus card, this is my lspci output: As it happens so am I. I have Nexus as a ff card and as a second card I have a budget card. dmesg . DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-CA rev1.X) DVB: registering new adapter (TT-Budget/WinTV-NOVA-C PCI) . The Nexus card is a ff card which I am using for video out. Firmware is the latest with the avsync fix. A small correction. I have two vdr boxes and I reported the wrong one for the hw :) The correct hw is: DVB: registering new adapter (Technotrend/Hauppauge WinTV DVB-C rev2.X) So it is not a Nexus-CA. But it is a ff card and I do not have another card on my second system. And the firmware is the same. On my systems the limits are: $ grep . /proc/sys/fs/file-* /proc/sys/fs/file-max:21190 /proc/sys/fs/file-nr:4320 0 21190 And mine $grep . /proc/sys/fs/file-* /proc/sys/fs/file-max:50644 /proc/sys/fs/file-nr:1088 0 50644 Also correct values for these are $grep . /proc/sys/fs/file-* /proc/sys/fs/file-max:50569 /proc/sys/fs/file-nr:7040 50569 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
Kartsa wrote:
I was about to test the performance of vdr when I stumbled on this message
ERROR: /dev/dvb/adapter0/demux0: Too many open files
I do not recall seeing this earlier. This came when fourth simultaneous
recording started.
Is this a vdr, dvb, or firmware issue? Seems like dvb but I really do
not know.
This is what was in the log after the fourth recording
Feb 19 21:53:00 vdr: [2226] timer 4 (7 2153-2200 'TestRec4') start
Feb 19 21:53:00 vdr: [2226] record
/srv/vdr/TestRec4/2007-02-19.21.53.50.99.rec
Feb 19 21:53:00 vdr: [2226] ERROR: /dev/dvb/adapter0/demux0: Too many
open files
Feb 19 21:53:00 vdr: [2226] ERROR (dvbdevice.c,673): Too many open files
Feb 19 21:53:00 vdr: [2226] ERROR: can't set PID 680 on device 1
Feb 19 21:53:00 vdr: [2226] ERROR (dvbdevice.c,688): Bad file descriptor
grep -20 -r EMFILE *
dvb/dvb-core/dmxdev.c-static int dvb_demux_open(struct inode *inode, struct
file *file)
dvb/dvb-core/dmxdev.c-{
dvb/dvb-core/dmxdev.c- struct dvb_device *dvbdev = file-private_data;
dvb/dvb-core/dmxdev.c- struct dmxdev *dmxdev = dvbdev-priv;
dvb/dvb-core/dmxdev.c- int i;
dvb/dvb-core/dmxdev.c- struct dmxdev_filter *dmxdevfilter;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- if (!dmxdev-filter)
dvb/dvb-core/dmxdev.c- return -EINVAL;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- if (mutex_lock_interruptible(dmxdev-mutex))
dvb/dvb-core/dmxdev.c- return -ERESTARTSYS;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- for (i = 0; i dmxdev-filternum; i++)
dvb/dvb-core/dmxdev.c- if (dmxdev-filter[i].state ==
DMXDEV_STATE_FREE)
dvb/dvb-core/dmxdev.c- break;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- if (i == dmxdev-filternum) {
dvb/dvb-core/dmxdev.c- mutex_unlock(dmxdev-mutex);
dvb/dvb-core/dmxdev.c: return -EMFILE;
dvb/dvb-core/dmxdev.c- }
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- dmxdevfilter = dmxdev-filter[i];
dvb/dvb-core/dmxdev.c- mutex_init(dmxdevfilter-mutex);
dvb/dvb-core/dmxdev.c- file-private_data = dmxdevfilter;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- dvb_ringbuffer_init(dmxdevfilter-buffer, NULL, 8192);
dvb/dvb-core/dmxdev.c- dmxdevfilter-type = DMXDEV_TYPE_NONE;
dvb/dvb-core/dmxdev.c- dvb_dmxdev_filter_state_set(dmxdevfilter,
DMXDEV_STATE_ALLOCATED);
dvb/dvb-core/dmxdev.c- dmxdevfilter-feed.ts = NULL;
dvb/dvb-core/dmxdev.c- init_timer(dmxdevfilter-timer);
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- mutex_unlock(dmxdev-mutex);
dvb/dvb-core/dmxdev.c- return 0;
dvb/dvb-core/dmxdev.c-}
IOW you ran out of filters.
yes, the error code should probably be different (eg EBUSY).
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
Artur Skawina kirjoitti:
Kartsa wrote:
I was about to test the performance of vdr when I stumbled on this message
ERROR: /dev/dvb/adapter0/demux0: Too many open files
I do not recall seeing this earlier. This came when fourth simultaneous
recording started.
grep -20 -r EMFILE *
dvb/dvb-core/dmxdev.c-static int dvb_demux_open(struct inode *inode, struct
file *file)
dvb/dvb-core/dmxdev.c-{
dvb/dvb-core/dmxdev.c- struct dvb_device *dvbdev = file-private_data;
dvb/dvb-core/dmxdev.c- struct dmxdev *dmxdev = dvbdev-priv;
dvb/dvb-core/dmxdev.c- int i;
dvb/dvb-core/dmxdev.c- struct dmxdev_filter *dmxdevfilter;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- if (!dmxdev-filter)
dvb/dvb-core/dmxdev.c- return -EINVAL;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- if (mutex_lock_interruptible(dmxdev-mutex))
dvb/dvb-core/dmxdev.c- return -ERESTARTSYS;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- for (i = 0; i dmxdev-filternum; i++)
dvb/dvb-core/dmxdev.c- if (dmxdev-filter[i].state ==
DMXDEV_STATE_FREE)
dvb/dvb-core/dmxdev.c- break;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- if (i == dmxdev-filternum) {
dvb/dvb-core/dmxdev.c- mutex_unlock(dmxdev-mutex);
dvb/dvb-core/dmxdev.c: return -EMFILE;
dvb/dvb-core/dmxdev.c- }
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- dmxdevfilter = dmxdev-filter[i];
dvb/dvb-core/dmxdev.c- mutex_init(dmxdevfilter-mutex);
dvb/dvb-core/dmxdev.c- file-private_data = dmxdevfilter;
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- dvb_ringbuffer_init(dmxdevfilter-buffer, NULL, 8192);
dvb/dvb-core/dmxdev.c- dmxdevfilter-type = DMXDEV_TYPE_NONE;
dvb/dvb-core/dmxdev.c- dvb_dmxdev_filter_state_set(dmxdevfilter,
DMXDEV_STATE_ALLOCATED);
dvb/dvb-core/dmxdev.c- dmxdevfilter-feed.ts = NULL;
dvb/dvb-core/dmxdev.c- init_timer(dmxdevfilter-timer);
dvb/dvb-core/dmxdev.c-
dvb/dvb-core/dmxdev.c- mutex_unlock(dmxdev-mutex);
dvb/dvb-core/dmxdev.c- return 0;
dvb/dvb-core/dmxdev.c-}
IOW you ran out of filters.
yes, the error code should probably be different (eg EBUSY).
So, why did I ran out of filters? Why did it happen? Why doesn't it
happen on my other vdr box? And what does it cause? The recording did
succeed.
\\Kartsa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Too many open files - error
Hello, I would try to check which files are open when it happens. Maybe the cause is something different, e.g. a not well programed plugin. lsof -p pid of vdr is your friend. ;-) Additionally you should check the currently defined limits on your system(s) with ulimit. Just my 2 cents, -- Patrick Cernko | mailto:[EMAIL PROTECTED] | http://www.errror.org A blue screen is nothing to worry about, just press [CTRL]+[ALT]+[DEL] and format c: (anonym) signature.asc Description: OpenPGP digital signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: Pokasaha
Iltaa, 18v riittää. Silloin on lapsen soundi kadonnut jo suurin piirtein äänestä. 16v:llä tuota soundia on aivan liikaa. Anna on taitava ei siinä mitään, mutta kyllä siitä laulusta puuttuu vielä monta astetta kun vertaa muihin kokeneempiin kilpailijoihin. Ja olisihan se hauskaa, kun 147 cm ja 35 kg ja 16+ vuotta astuu stadionille viihdyttämään kymmentuhatpäistä yleisöä. Tenavatähdille on omat kisat... No, katsoppa miltä näyttä Kylie Minoque.. 145cm, 40kg?, mutta 30-40v.. Juttuhan on siinä ettei niitä tarvitse pahemmin säätää kun ne ovat valmiiksi laitettu kohdalleen (ellet sitten asenna runkoja kieroon). Ehkä jotain pientä viilausta joutuu tekemään, mutta ei pahemmin muuta. Ja tuo pikakiinnitys on todella kaukana siitä, että joutuu ruuvaamaan saranat paikoilleen - oli sitten reiät valmiina tai ei. Meneehän siihen aikaa, mutta kun ajattelet sitä, että reiät ovat valmiina tai teräväkärkisille ruuveille niiden paikat. Ruuvithan ovat keittiösaranoissa jo valmiiksi saranassa kiinni. Ja näinhän se menee: Napsautat pari saranaa ovessa oleviin isoihin reikiin ja akkukoneella narks, narks, narks ja narks. Sitten laitat kaapin seiniin vastakappaleet samallla tavalla. Tämän jälkeen pukkaat oven paikalleen, säädät ja se on siinä. Kahvojen kanssa tappaelet joka tapauksessa, ellet ota valmista pakettia asennuksineen. Kyllä kyllä. Ei tuossakaan hirveästi menee aikaa, mutta et voi väittää etteikö ne pikalukitteiset ole monin verroin nopeampia asentaa eikä varmasti tule virheitä kuten liian kovasti kiritys. Pikasaranoilla homma menee näin: Ovessa ovat paikallaan, ehkä myös kaapissa -ainakin suurin osa. Napsautat paikalleen ja säädät kohdalleen. Riippuu tosin siitä kuinka valmiiksi ne on säädetty tehtaalla. Muta, tästä voi pikkaisen extraa maksaakin. Molempia pitää ajan saatossa säädellä. Toki. Säästöä syntyy varmasti, koska muuten noita ei tehtäisi. Ihmiset haluavat halpaa ja sitä tuolla menetelmällä saa. Onhan tuossa se etu, että tulee niin kuin automaattisesti syy vaihtaa ovet tietyn ajan jälkeen :) 8 000 euroa peruskivasta keittiöstä ei ole halpaa Aika isosta peruskeittiöstä puhut, jos 8000€ maksaa. Nämä peruskeittiöt mitä katselin maksoivat tuolta alle 3000€ tuonne reiluun 5000€ eivätkä olleet maalatuilla ovilla.. Keittiökoneita ei hintaan voi eikä saa laskea. Kysyin myös maalatuista ovista, mutta eivät nekään säästy tältä ongelmalta. Tätä rako-ongelmaa ei niissä ole. Muitakaan ongelmia en ole vielä havainnut: kulumaa ei havaittavasti eivätkä mene kieroon. Kosteus menee läpi vaikka et näkisi tuota rakoa. Jos käyt testaamassa nyt 4-vetoista niin voi hyvinkin olla autonvaihto ajankohtaista :) 2 -vetoisella on paljon jännempää... Pääseekö ylämäestä risteyksessä lähtemään valojen palaessa vihreinä vai pitääkö odottaa seuraavatkin valot ja kuunnella torvi-orkesteria takanaolevilta.. Niin, onhan tuokin yksi tapa saada jännitystä elämään.. Onko Jaska aikeissa maasturin hommata? Siis oikean maasturin vai sellaisen city-härpäkkeen, joissa ei ole edes lukkoa? Toyotan RAV taitaa olla listan ykkösenä, kunhan saa vaan sen tyylin autoon luvan ;-) . Jaa jaa. Nämä nyt ei niitä maastureita ole nähneetkään eikä Jaskan kannattaisi tällaiseen sormiaan sotkea jos meinaa sitä käyttää pelloilla jne. Huvittava yksityiskohta: 3,2l vapari tarjoaa 250hv ja 320Nm, kun taas 2,0l dieseli tarjoaa 170hv ja 350Nm. Pieniltä tuntuvat erot, mutta huipuissa ja kiihtyvyydessä on yllättävän suuri ero: 0-100km/h yli 1s hitaampi dieselinä. Diesel on mun juttu, ainakin vielä, kun tulee noita kilometrejäkin. Paljonko pitää tällä hetkellä ajaa, että dieseli kannattaa? Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Hi, Reinhard Nissl wrote: Please provide me some of these files which were dumped in the middle of a recording. If size matters, you may reduce the number of packets to 100. I had a look into the files you've provided me. It looks like some TS packets get lost. You can simply check this on your own: od -Ax -t x1 -w188 -v ts_10973_11079_0xC0_004_116796_1000.log \ | tail -n 20 | less -S will give you something like the lines below (I've croped the long lines here for readability). Just have a look a the marked column: v v 02d06c 47 02 94 13 24 84 c0 8b 02d128 47 02 94 14 44 91 b9 1b 02d1e4 47 02 94 15 a5 ab ab a1 02d2a0 47 02 94 16 40 b4 0c c2 02d35c 47 02 94 17 5d c5 6b 5f 02d418 47 02 94 18 72 5c 3e 84 02d4d4 47 02 94 19 05 81 b4 7e 02d590 47 02 94 1a 95 ba dc 2c 02d64c 47 02 94 1b 86 86 fe 12 02d708 47 02 94 1c 2b 22 a6 d9 02d7c4 47 02 94 1d b9 b5 e2 6d 02d880 47 02 94 1e e4 6e 11 17 02d93c 47 02 94 1f 90 00 00 00 02d9f8 47 02 94 10 ca 1b 20 ed 02dab4 47 02 94 11 55 d5 c6 73 02db70 47 02 94 10 e8 69 4d 5a 02dc2c 47 02 94 11 d8 e5 9a 69 02dce8 47 02 94 12 ac 2a 65 ba 02dda4 47 02 94 13 62 35 d1 c4 02de60 ^ ^ This nibble represents the TS continuity counter. It cycles properly from 0 to 9 and a to f throughout the file. But near the end the following sequence appears: e f 0 1 . . . . . . . . . . . . . . 0 1 2 3 The dot's indicate at least the missing TS packets with counter values: _ _ _ _ 2 3 4 5 6 7 8 9 a b c d e f _ _ _ _ I wonder why you didn't get lines like the following in your logfile after enabling the earlier mentioned source lines and specifying -l 3 on VDR's command line to turn on debug log messages: Feb 20 21:41:14 video vdr: [27499] TS continuity error (1) Feb 20 21:41:15 video vdr: [27499] cTS2PES got 0 TS errors, 1 TS continuity errors Sad to say, I can hardly help you further as lost TS packets can be caused by a couple of reasons: - Dish alignment - Weather conditions - Cabling - Interference with DECT telephones - DMA/PCI mainboard issues - High system load / latency - DVB driver issues As you can see, VDR just picks up what survived the above stages. I had lost TS packets over and over just after replacing my PATA drive by a SATA drive to have the PATA one sent in for repair. I've contacted the dvb-mailing list and got driver patches for larger DMA buffers. Extremely large buffers seemed to fix the problem but not completely. After the PATA drive returned from repair, I've removed the SATA drive and -- you won't believe it -- everything worked out of the box as before, even with default drivers (I won't blame here SATA in general -- this is just my personal experience at that time with certain hardware). BTW: You may wonder why you do not get these messages when watching live TV with a FF card. The answer is simple: the TS packets never leave the card in this case, so VDR has no way to report such an issue for example in case where the problem would be related to dish alignment. But when you start a recording for example on a single FF card system, TS packets will then be sent to VDR for the recording and for live TV, so if you continue to watch the recorded channel, you'll typically get the cRepacker messages twice for different threads. 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] FF card AV sync problems, possible fix to VDR (fwd)
OK, so Karsta and I are suffering dropped TS packets. I know for sure that my DVB-T signal is not perfect so it is likely to occasionally lose some TS packets (freeview in the UK is susceptible to all sorts of interference from cars, motorbikes, DECT, etc) however, saying there is nothing that we can do about this because you don't have a *perfect* DVB signal surely isn't the right answer! My TV copes perfectly well with dropped packets and doesn't go out of sync, as does my freeview box. Surely if some TS packets are dropped this shouldn't result in a loss of sync, the system should resync the audio and continue as before?? It can't be right to say, well we lost some data, so we can't recover until you change channels up and down, or fastforward/rewind by 1 minute! I have spent the last 2 weeks trying different combinations, playing with my kernel settings, trying USB DVB-T devices rather than the PCI and it makes absolutely no difference. The TS continuity errors do not go away so I am convinced it is simply that DVB-T is not as robust as other signals such as DVB-S or DVB-C. However, VDR should be able to cope and resync with lost data. Regards, Morfsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Pokasaha
Sorry about this. Thunderbird plugin automatically added several addresses and I didn't notice these before it was too late. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Hi,
Morfsta wrote:
OK, so Karsta and I are suffering dropped TS packets. I know for sure
that my DVB-T signal is not perfect so it is likely to occasionally lose
some TS packets (freeview in the UK is susceptible to all sorts of
interference from cars, motorbikes, DECT, etc) however, saying there is
nothing that we can do about this because you don't have a *perfect* DVB
signal surely isn't the right answer! My TV copes perfectly well with
Well, what I wanted to say is that I cannot help you any further at this
point. You have to check your hardware/driver whether there is a chance
to minimize packet loss. You did this already as you wrote below -- fine.
dropped packets and doesn't go out of sync, as does my freeview box.
Surely if some TS packets are dropped this shouldn't result in a loss of
sync, the system should resync the audio and continue as before?? It
can't be right to say, well we lost some data, so we can't recover until
you change channels up and down, or fastforward/rewind by 1 minute!
You are right -- but don't you think that this thread got a bit off
topic? I've replied in this thread because there were cAudioRepacker
messages and as I've contributed this code to VDR I just wanted to make
sure that it works correctly in this case. Let's now come back to the
topic and concentrate on the AV sync issue.
I have spent the last 2 weeks trying different combinations, playing
with my kernel settings, trying USB DVB-T devices rather than the PCI
and it makes absolutely no difference. The TS continuity errors do not
go away so I am convinced it is simply that DVB-T is not as robust as
other signals such as DVB-S or DVB-C. However, VDR should be able to
cope and resync with lost data.
Well, basically this is not a matter of VDR but of the FF card's
firmware. For example, I do not own a FF card and do not see this AV
sync issue with xine, even when I intentionally drop TS packets by the
attached patch.
I'd like users of FF cards to test this patch. If this triggers AV sync
issues, firmware developers are invited to fix this issue.
Feel free to modify this patch to better simulate real TS packet losses
like bursts of 16 frames.
BE WARNED: *** do not use this patch on a production system ***
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.4.5-orig/remux.c 2006-12-01 15:46:25.0 +0100
+++ remux.c 2007-02-21 00:06:03.0 +0100
@@ -1805,7 +2278,7 @@ void cTS2PES::instant_repack(const uint8
{
if (!Buf)
return;
-
+if ((rand() * 100.0 / RAND_MAX) = 0.05) return; // cause 0.05 % TS packet loss
if (Buf[1] TS_ERROR)
tsErrors++;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
R: [vdr] VDR Multiple frontends - Function to detect if recording in progress
Hi, To finishing adding multiple frontend support, I need a function to know inside dvbdevice.c if recording is in progress. Is there a function ready? Best Regards, Eddi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
