Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: > Oliver Endriss wrote: >> Does mplayer really play PES data 'as is'? >> Afaik it recodes data to MPEG-1.(?) > > From CPU load on my machine, mplayer cannot do much with the signal. The > CPU load is even lower than the VDR load when playing back 001.vdr. And > even decoding in sotware would out-run my machine. > > But I guess they decode the PES stream into two ES streams with > additional timing, and re-pack it to a new PES stream. > Would it be very difficult to duplicate this in VDR? I would love to start trying out code. My programming skills are just not good enough to start implementing this task. But, once there is some framework, I can get by trying things out. > Which leads to the open question, does the firmware/driver get confused > by slight jitter in PTS values of audio PES packets? Or is this > compensated? > What if the reception goes out for long periods of time and the sync becomes really bad? The firmware must have more limitations than a software solution? Best Regards. N.B. Thanks to everyone that is looking into this further! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: > > On 24 Oct 2006, at 12:44, C.Y.M wrote: > >> Somehow, mplayer is able to detect the areas in the VDR recordings >> that need >> extra "padding" to keep the sync. There must be some kind of pattern >> in the >> data that the player recognizes and it knows it must insert a null >> frame. How >> to go about finding how it works and creating an algorithm. > > So you're certain that it's always picture frames being dropped, causing > audio to be behind the video? > >From what I understand, it could be either video or audio that is using "stacked" data. Either a video frame that does not "change" or perhaps a few seconds of silence on the audio track could trigger this. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Joerg Knitter wrote: > Klaus Schmidinger wrote: >> C.Y.M wrote: >>> Since it has been several years now and I have never been able to >>> solve the a/v >>> desync issues with my Nexus-S FF card when playing back recordings... >> >> I'm replaying many recordings (actually most of what I watch >> are recordings ;-) and don't even remember when was the last >> time I had an A/V desync. > > There is one more issue, that seems to be related. On some recordings, > here RTL Television with AC3 playback, sometimes single frames seem to > be skipped during playback. I watched a recording of "Alarm für Cobra > 11" yesterday and could identify at least 6 little jumps. > > I have isolated a 20 MByte part of this recording where this effect was > clear to see - I can send it by seperated mails or upload it somewhere > if someone gives me an URL. > > The weird thing: Playing those isolated scenes does not show the effect > as people can see if they play the whole recording from the beginning, > but rewinding the short clip to a certain point makes it possible to > reproduce the problem. And again: This just happens when playing back > the AC3 audio track. > Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Chad Flynt wrote: > I am sure this is more widespread than people imagine. I know that > everyone I talk to has this issue. But most don't participate on the > ML. There are forums that have talked bout it all over. Most of us > have just as said, gotten used to it and assumed it will never be > addressed. So I too am glad to see it being discussed once again, and > do hope there can be a resolution. I wish I understood more about how > it all pieced together to help. > The problem seems extra prevalent when watching cartoons. I would assume that many of the frames are repeated the same during the voice over and because they're using "stack" compression, they won't send any empty (null) frames. This is why the A/V desync is so terrible whenever I try to watch the Simpsons. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
> Recordings are pure PES packet sequences of video and audio PES packets. > PCR is not recorded. On playback, the PES packets are forwarded to the > DVB driver without further modification. IMHO the playback sync only > uses the PTS of the PES packets, however thats just guessing. > If PCR is ignored that violates spec. If frames are missing, I would consider that a pretty huge bug. > I'm not sure if the PES repacker does anything on recording or if PCR is > used only on live. There are not much German channels with PCR on Astra > anyway. > > (look for VPID with nnn+nnn form in channels.conf) > Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Juri Haberland wrote: > "C.Y.M" <[EMAIL PROTECTED]> wrote: >> Guy Roussin wrote: >>>>> if i make this, the file play fine (vdr ffcard) : >>>>> >>>>> mv 001.vdr _001.vdr >>>>> mv index.vdr _index.vdr >>>>> mplayer -vo mpegpes:001.vdr -ao mpegpes 001.vdr >>>>> genindex >>>>> >>>>> But now the file 001.vdr is 100Mb ! >>>> Am I doing something wrong? I dont seem to have any sound.. also if you >>>> move >>>> 001.vdr to _001.vdr, then the command below will not be able to find the >>>> file. >>>> :) >>> Sorry for the typo : >>> >>> mplayer -vo mpegpes:001.vdr -ao mpegpes _001.vdr >>> >> hmm.. I'm not getting any sound when I do this. If I perform the command >> when >> VDR is not running, I see the video being written to file, but I can hear the >> sound through the speakers. Also, the resulting file is much smaller >> indicating > > try with (just a guess) > mplayer -vo mpegpes:001.vdr -ao mpegpes:001.vdr _001.vdr > That was my initial thought too. No luck so far. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Guy Roussin wrote: >>> if i make this, the file play fine (vdr ffcard) : >>> >>> mv 001.vdr _001.vdr >>> mv index.vdr _index.vdr >>> mplayer -vo mpegpes:001.vdr -ao mpegpes 001.vdr >>> genindex >>> >>> But now the file 001.vdr is 100Mb ! >> Am I doing something wrong? I dont seem to have any sound.. also if you move >> 001.vdr to _001.vdr, then the command below will not be able to find the >> file. >> :) > > Sorry for the typo : > > mplayer -vo mpegpes:001.vdr -ao mpegpes _001.vdr > hmm.. I'm not getting any sound when I do this. If I perform the command when VDR is not running, I see the video being written to file, but I can hear the sound through the speakers. Also, the resulting file is much smaller indicating the audio has been removed. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Guy Roussin wrote: > Tero Siironen <[EMAIL PROTECTED]> wrote : >> Here is a 3 minute clip from the episode of Lost I told earlier. >> http://kotisivu.suomi.net/izero/lost.tar >> >> 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X >> > if i make this, the file play fine (vdr ffcard) : > > mv 001.vdr _001.vdr > mv index.vdr _index.vdr > mplayer -vo mpegpes:001.vdr -ao mpegpes 001.vdr > genindex > > But now the file 001.vdr is 100Mb ! > -- Am I doing something wrong? I dont seem to have any sound.. also if you move 001.vdr to _001.vdr, then the command below will not be able to find the file. :) Good info though! Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: > Tero Siironen wrote: >> Here is a 3 minute clip from the episode of Lost I told earlier. >> http://kotisivu.suomi.net/izero/lost.tar >> >> 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X > > I've checked your recording. Lost "The other 48 days" - surely one of > the worst episodes for me too, because the fade-to-black on every day > break. > > Your recording however runs relatively fine on my FF (r1.6 firmware > f22623) card. There's noticeable audio stuttering after the > fade-to-black scenes, but audio desync is only small, though noticeable. > > Demultiplexing with ProjectX throws 11649 of errors like this: > > !> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / > true / false) > !> error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 / > true / false) > > pos is changing, the rest seems always the same. > > I then re-muxed the elementary streams and converted them back to VDR, > and the resulting video played fine again. So this issue seems to be > some problem on the PES packaging layer. > > In contrast, my recording issue cannot be fixed by re-muxing, and has > more noticeable audio desync, its probably a totally different issue. > The dev's already have a sample file. > It is postulated that vdr takes whatever it gets and shoves it into the playback buffers of the a/v decoder in whatever order it is in. In live TV this is rate-limited meaning the clocking source is the network and the network transmits at whatever rate it needs to and the decoder decodes it. So, let us say that time is "x". If video is transmitted faster than rate "x", and audio also is transmitted faster than time "x", then we get a xrun. I think that's understood. But, if video is transmitted faster, then slower, then faster, then slower etc, but drifts around time "x", and is not sent to the decoder at any other speed than "x", then the decoder gets a constant smooth stream. Because if it takes x+3 ms to play something, the input stream on livetv won't overfill its buffer because the next run will be x-3 ms and so the extra time is made up. This is very easily seen with variable framerates and bitrates. Audio also might be doing the same thing, where it send at spurts rather than a steady stream. Now if audio and video are both spurting along, where do you find a common time? IRL, time is constant. But on playback if vdr doesn't clock its data, then desync is quite possible. For example, if there's nothing to "change" for a few video frames, because they're using "stack" compression they won't send an empty frame. So, consider this blackout time in "Lost". The theory is that problems are occurring because they're not sending empty null frames. Also, if they're clocking on video, not audio. You will get your sync problems because you're missing bits. Does VDR store the pcr pid in the recordings? Is the pcr used during playback to clock the data? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: > > On 22 Oct 2006, at 22:33, C.Y.M wrote: > >>> >>> And just for completeness: No serious CPU load when playing back with >>> VDR or mplayer. >>> >> >> Yes, if the extra CPU load by mplayer is not even noticeable when >> playing back >> VDR recordings, and it is not prone to any type or desync, then I vote >> we all >> try to figure out what mplayer is doing and repeat it. Whats a few >> extra CPU >> cycles if it becomes much much more stable in the end. > > The reason i mentioned the dvbplayer.c thread, is that this problem was > mitigated by using different code to feed the softdevice mpeg2 decoder; > using softplay to playback recordings provided dropout free playback. > I'm not sure if softplay works with FF cards, but you might get the > source at softdevice.berlios.de to give it a try. > I use xine with my FF card and it works flawlessly and fixes all my problems, but since I never had trouble with the FF card when just watching live TV, I thought it was such a waste of CPU to have to use software decoding for everything. I only have problems when playing back recordings with the FF card. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: > C.Y.M wrote: >> mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc >> -quiet 001.vdr >> >> Notice that "-framedrop" is added to the command line. I wonder if >> that is the >> reason why mplayer is "immune" to the a/v desync problem. > > Definitely not just that. My playback issue already disappears when > using the most simple command line: mplayer -vo mpegpes -ao mpegpes > 001.vdr. > > And just for completeness: No serious CPU load when playing back with > VDR or mplayer. > Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end. Thanks everyone for chiming in on this one. I really hope that this time we can stop passing the buck and just git'r done. :) Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: > > On 21 Oct 2006, at 20:22, C.Y.M wrote: > >> >> Yes, it still happens on every firmware revision. But, I really dont >> think this >> is a firmware issue as much as it is a VDR one. There must be several >> ways to >> approach this problem but the best way would be an open source >> solution IMHO. If >> mplayer can successfully forward the video every time straight to the >> FF card >> w/o any transcoding, then why cant VDR do the same thing? Im sure >> someone can >> post links to problematic recordings if you need some to test with. > > Could anyone with this problem see if they have high cpu utilization in > the dvbplayer.c thread when the sync problems occur? > Are you thinking that mplayer might be dropping bad frames more efficiently than VDR? Is it possible that VDR is not dropping the bad frames properly, thus causing dvbplayer.c to struggle when processing/forwarding the video to the FF DVB card? This is the command used when playing back DVB compliant VDR recordings to a FF card with mplayer: mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr Notice that "-framedrop" is added to the command line. I wonder if that is the reason why mplayer is "immune" to the a/v desync problem. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
>> My theory is that since audio is typically 600ms ahead of video, maybe >> the audio buffers run over. Strange thing is why this happens >> reproducible on blackness. Maybe due to extremely low bit rate in this >> situation, more frames get packed into one data block, causing data flow >> to be disturbed beyond some limit. It cant be too high data rate, ATV+ >> has just 2mbit avg, 4mbit max data rate. > > Does it also occur with the latest test firmware? > http://www.suse.de/~werner/test_av-f22623.tar.bz2 > > If yes, please provide short sample clips. > Please verify that the clips are not damaged, i.e. they play fine with > mplayer or xine. > Yes, it still happens on every firmware revision. But, I really dont think this is a firmware issue as much as it is a VDR one. There must be several ways to approach this problem but the best way would be an open source solution IMHO. If mplayer can successfully forward the video every time straight to the FF card w/o any transcoding, then why cant VDR do the same thing? Im sure someone can post links to problematic recordings if you need some to test with. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Klaus Schmidinger wrote: > C.Y.M wrote: >> Klaus Schmidinger wrote: >>> C.Y.M wrote: >>>> ... [ problem with A/V desync ] >>>> I would have to say that this is exactly the same thing I have been >>>> experiencing >>>> for years and years. But, this never happens with budget cards.. only >>>> FF cards. >>> I'm not sure what you mean here. Budget cards can't replay, >>> so it's clear that this problem can't happen with them. >>> >>> Or are you saying that this only happens with recordings >>> made from FF cards, and not with recordings made from >>> budget cards? Both, of course, replayed via a FF card. >>> >> >> What I was trying to say is that the recordings are not damaged. They >> seem to >> playback fine with a software decoder on both FF and budget cards. > > There you go again: a software decoder *can't* replay "on a budget card". > This is just nonsense (sorry, no offense). OK, I understand what you are saying because nothing outputs through a budget card. What I meant to say is that a recording from a budget card and a recording from a FF card both play the same when using a software decoder such as xine. > >> I think that >> Udo has brought up a very good point about why mplayer is "immune" to >> the a/v >> desync problem when just using mpegpes to forward the video to the FF >> dvb card. > > What VDR sends to the FF DVB card *is* MPEG-PES. I wouldn't know > what to do differently - but apparenty mplayer does some magic, > so if this can be found out, it might help. > ACK. I hope that someone who understands the mpegpes code in mplayer can shed some light on this. What kind of repacking is mplayer doing that fixes this problem. It is definitely not transcoding the video. All it is doing is forwarding the video to the dvb card via mpegpes. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Klaus Schmidinger wrote: > C.Y.M wrote: >> ... [ problem with A/V desync ] >> I would have to say that this is exactly the same thing I have been >> experiencing >> for years and years. But, this never happens with budget cards.. only >> FF cards. > > I'm not sure what you mean here. Budget cards can't replay, > so it's clear that this problem can't happen with them. > > Or are you saying that this only happens with recordings > made from FF cards, and not with recordings made from > budget cards? Both, of course, replayed via a FF card. > What I was trying to say is that the recordings are not damaged. They seem to playback fine with a software decoder on both FF and budget cards. I think that Udo has brought up a very good point about why mplayer is "immune" to the a/v desync problem when just using mpegpes to forward the video to the FF dvb card. BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: > C.Y.M wrote: >> Utilizing mpegpes is really the best of >> both worlds. We would still be using the video output on the FF card >> but having >> software to process the actual mpeg decoding. There would be no >> transcoding >> involved because obviously the recording would already be in a DVB >> resolution >> format. > > This leaves the question: If the video is already in DVB compatible > mpeg2 format, what does mplayer do before forwarding the data stream to > the DVB card, that VDR does not? > Basically, VDR just forwards the whole data stream to the DVB driver. If > mplayer is immune against stream desyncing, then they must do some > repacking/fixing to the data stream that helps the DVB hardware on > decoding. > If the answer to this question could be discovered, then problem solved. So, what you are suggesting is VDR is not doing something that mplayer is doing that fixes the problem. Hmm... so then it is not a driver or firmware issue after all?? Could we agree that much? :) This has been back and forth for a long long time with the drivers development team and Klaus. hehe. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Juri Haberland wrote: > Klaus Schmidinger <[EMAIL PROTECTED]> wrote: >> C.Y.M wrote: >>> Since it has been several years now and I have never been able to solve the >>> a/v >>> desync issues with my Nexus-S FF card when playing back recordings... >> I'm replaying many recordings (actually most of what I watch >> are recordings ;-) and don't even remember when was the last >> time I had an A/V desync. > > I also have A/V desyncs. This is with one TT-DVB-T (and a > TT-DVB-C, most of the time we record and watch via the DVB-T card). > > In most cases it is bad reception. > Pausing and restarting the video fixes it - most of the time - but > sometimes I have to switch back to live TV and restart the video. > >> Are you getting this with recordings from particular channels, >> or does it happen all the time? >> Also, is this with MPEG audio or AC3? > > There is no AC3 involved - just plain replay via FBAS and audio out > of the TT card. > The A/V desync problem would not be so critical if it corrected itself with some type of time code. In fact, even playing bad recordings back with some kind of software decoder can give you a desync once in a while, but the difference is that the software method fixes the desync automatically (without having to fast forward or rewind to the next GOP). Utilizing mpegpes is really the best of both worlds. We would still be using the video output on the FF card but having software to process the actual mpeg decoding. There would be no transcoding involved because obviously the recording would already be in a DVB resolution format. The CPU usage would be very minimal and I would not need to install X-windows or some type of framebuffer. I am just talking about regular MPEG audio/video. It doesn't seem like it would "that" hard to modify the mplayer plugin for just this purpose. In fact, it already works. But there are a few minor issues with it. 1) Mplayer can not get the correct seek time when playing back VDR recordings for some reason (causing the time bar to show incorrect values). 2) Mplayer can not handle playing back split files (ie; 001.vdr, 002.vdr). As of now each one must be selected individually. 3) Sometimes when playing back a video with mplayer (using only a single FF card in the machine), something puts a lock on something in /dev/dvb/adapter0/*. So, if a timer should happen to go off in VDR while you are playing back a video with mplayer, VDR will crash when attempting to start recording with the timer. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
C.Y.M wrote: > Udo Richter wrote: >> Tero Siironen wrote: >>> However, like Pasi Juppo told earlier in other thread, in last weeks >>> episode >>> of Lost there was many fadeout-fadeins between scenes and a/v desync >>> happened on every one of these. >> I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade >> into black, the data stream seems to get stuck, frames get delayed, and >> as consequence A/V desyncs and playback gets jerky, with lots of audio >> and video frame drops. This can be fixed by pausing and jumping a few >> frames backwards. >> >> My theory is that since audio is typically 600ms ahead of video, maybe >> the audio buffers run over. Strange thing is why this happens >> reproducible on blackness. Maybe due to extremely low bit rate in this >> situation, more frames get packed into one data block, causing data flow >> to be disturbed beyond some limit. It cant be too high data rate, ATV+ >> has just 2mbit avg, 4mbit max data rate. >> > > This theory sounds reasonable. Any idea on a way to fix it? The biggest > question is if it can be fixed from within VDR's source code or if it would > require an additional firmware/driver revision. I have given up hope on it. > The only way I know of that is reliable is using software decoding. > But, the biggest question is.. why does the ONLY happen when playing back recordings?? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: > Tero Siironen wrote: >> However, like Pasi Juppo told earlier in other thread, in last weeks >> episode >> of Lost there was many fadeout-fadeins between scenes and a/v desync >> happened on every one of these. > > I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade > into black, the data stream seems to get stuck, frames get delayed, and > as consequence A/V desyncs and playback gets jerky, with lots of audio > and video frame drops. This can be fixed by pausing and jumping a few > frames backwards. > > My theory is that since audio is typically 600ms ahead of video, maybe > the audio buffers run over. Strange thing is why this happens > reproducible on blackness. Maybe due to extremely low bit rate in this > situation, more frames get packed into one data block, causing data flow > to be disturbed beyond some limit. It cant be too high data rate, ATV+ > has just 2mbit avg, 4mbit max data rate. > This theory sounds reasonable. Any idea on a way to fix it? The biggest question is if it can be fixed from within VDR's source code or if it would require an additional firmware/driver revision. I have given up hope on it. The only way I know of that is reliable is using software decoding. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Tero Siironen wrote: > On 20.10.2006 15.09, "Klaus Schmidinger" <[EMAIL PROTECTED]> > wrote: > >> C.Y.M wrote: >>> Since it has been several years now and I have never been able to solve the >>> a/v >>> desync issues with my Nexus-S FF card when playing back recordings... >> I'm replaying many recordings (actually most of what I watch >> are recordings ;-) and don't even remember when was the last >> time I had an A/V desync. >> >> Are you getting this with recordings from particular channels, >> or does it happen all the time? >> Also, is this with MPEG audio or AC3? > > Well here in Finland the channels at least where I've seen this to happen > are two commercial channels (MTV3 and Nelonen). I don't remember seeing > those problems with non-commercial channels (YLE's channels). > > The a/v sync problems usually occur when commercial break ends and program > continues. But it happens also in the spots where there has been commercial > break in the original broadcast but not in here. > > However, like Pasi Juppo told earlier in other thread, in last weeks episode > of Lost there was many fadeout-fadeins between scenes and a/v desync > happened on every one of these. I preserved an example clip of this with > length of 3 minutes and there is four desync spots in it. So it is not > directly related to commercial breaks. I think this happens almost on every > recording made from these two channels. > > Audio is normal MPEG. I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards. My guess is that it is firmware/driver related. But, since only a handful of people have the source code to the firmware, it is virtually impossible to fix. we could work around it by using mplayer with mpegpes to playback the problematic recordings and live tv is never an issue. I would just like another way of playing back the recordings in VDR w/o having to rely on the firmware of the FF card that nobody can fix. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FF card A/V sync suggestion
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings, I was thinking about what could be done. As of now, I have been using xine with my FF card to fix the problem. But, if I use xine, then even live tv is played back over software. The problem was never with live tv, only playing back recordings. What if the mplayer plugin was modified to replace the default vdr playback for recordings. It currently works as is, but it has problems with split files (ie; 001.vdr, 002.vdr, etc.). Also, it would be nice if there was an option to replace the default playback in vdr for recordings (so we wouldnt have to select the mplayer plugin first every time). Just a suggestion, but using mplayer over mpegpes would definitely be a better solution for fixing the a/v desync instead of having to use xine for everything (since there never was a problem with live tv). Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR to Xine playback -- no Audio?
mlists wrote: > I'm running VDR 1.4.3 with hoochster's patches. > > I've install xine but I'm not getting any audio. When vdr starts up and > then xine -- I'm getting this: > vdr-xine: Client connecting ... > vdr-xine: Client connected! > [VM]buffered 50.2 frames (v:50.2, a:0.0) > buffered 51.5 frames (v:51.5, a:0.0) > > Is this what I should see? > That looks right, but it seems like alot of buffered frames. I think mine is set to buffer only 4 frames with a hysteric of 4. About the sound, what i did was loop the audio output of the nexus-s back into the line-in on my soundcard using that 1/8" stereo jack plug coming out of the nexus. Next, make sure you have your mixer settings correct. Good luck.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with audio sync in playback
Tero Siironen wrote: > On 14.10.2006 23.20, "Pasi Juppo" <[EMAIL PROTECTED]> wrote: > >> This problem is yet to be fixed to my understanding. Now I have a good >> recording (one episode from Lost) where this happens very often. The >> problem seems to be related to situations where the scene fades black >> before new scene. There is something strange in those situations.. >> >> If someone has the knowledge/talent to start debugging the problem I can >> put the recording available for downloading. > > Well, I don't have knowledge for debugging, but I ran some tests. I took few > minutes crop from a recording of same episodes and tried it with different > AV7110 firmwares. (TT DVB-C FF 2.1 card) > > I tested with VDR 1.4.3 and test_av app included in 22623 test firmware > package, with firmwares 261a, 261f, 2622 and that test version 22623. > Everytime playback stuttered and lost a/v sync after scene change situation. > > So I think this is more like dvb firmware/driver problem than VDR problem. > However this is very annoying. > > The only way i know how to fix that is to run your FF card with some kind of software playback (ie; xine). I wish we had a version of firmware that didn't have this problem.. or at least a way for it to recover itself. Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] runvdr extreme
Udo Richter wrote: > Peter Bieringer wrote: >> Thank you for the nice script. >> >> One fix is necessary: >> >> -[ -n "$VFAT" ] && VDRCMD="$VDRCMD -v" >> +[ -n "$VFAT" ] && VDRCMD="$VDRCMD --vfat" > > > Hmm, you're right. Thanks. I've missed that because my VDR is switched > to vfat on build time. > >> I found only one major difference to the one I've created over time: my >> script reboots the system if vdr won't proper start 3 times, perhaps you >> can add such feature > > Maybe optionally, I'll think about it. > I also have a suggestion. It is nice to have vdr startup in a screen session when working remotely. I'm using something like this: eval "screen -D -m -S vdr $VDRCMD &" This starts a screen in detached mode called "vdr" and keeps the same PID. When logging in remotely to the machine, vdr can be monitored by typing "sudo screen -r vdr". To detach, type: ctrl+a d Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] vdr-xine & xine-lib 1.1.2 (patch update)
V Live wrote: > What about the patches for xine-lib @ > http://www.youmustbejoking.demon.co.uk/patches/vdr-xine are they being > maintained too? > I have not seen them change for a while. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] vdr-xine & xine-lib 1.1.2 (patch update)
martin wrote: > Hey Darren, > > since some days, the xine-lib has changed a bit, so your patches fail > against version 1.1.3. I've updated all necessary patches, to make xine-lib > running with the current cvs version. You may want to update our patches on > your site! > What about "xine-lib_modify_expand_plugin.patch"? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ProjectX - won't start
lamikr wrote: > I am not sure from the installation of rpm versions, because I am just > used to download the .bin versions of sun jdk. > If you install the ".bin" version of Sun JVM, you can basically extract > it to any directory you want. > Then just make sure that the jdk/bin directory where java, javac, etc. > locates is first one in your path. > > After that, you can just launch it by using standard java command. > With some distros, you may need to update all java related symlinks from > /etc/alternatives directory to point to > files under your sun jdk instead of the default ones pointing to non-sun > version. > In Debian, you can use the following command to create java install packages. fakeroot make-jpkg j2sdk-1_4_2_12-linux-i586.bin BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Returning due to modification...
Klaus Schmidinger wrote: > Lauri Tischler wrote: >> Klaus Schmidinger wrote: >>> CR wrote: Hi, I notice when I change channels, video/audio will start and then it will pause and resume, in the syslog I often see "returning due to modification of channel " when it happens. In the setup options, I have turned off updating of any channels, so why does this occur? Is there anyway to avoid it/disable it? >>> >>> Are these channels encrypted? >>> If so, it retunes because of a change in the CA-IDs. >> >> Ummm.. terminology. >> Is changing pid considered 'retuning' ? >> Traditionally 'retuning' means actual change of frequency. >> Just asking. > > Well, if anything regarding the channel setup changes, > VDR switches to that channel again. If the frequency > didn't change, it actually just sets the pids to the > new values (or whatever else has changed). > The "retuning due to modification.." used to be the cause for all those zero byte sized recordings, but I think newer versions of vdr have a workaround for that problem. BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Announce: eggtimer-0.9.5 zaphistory-0.9.5 digicam-1.0.2 radiolist-0.0.2
Peter Juszack wrote: > Hallo everybody, > > >I finally managed to upload new versions of plugins which honor > APIVERSION and compile with VDR 1.4. > No other changes except Dutch translations for the eggtimer-plugin > > Plugins can be found at > http://turku.wi-bw.tfh-wildau.de/~pjuszack/digicam/ > When I tried to build eggtimer-0.9.5, I noticed that there is some missing syntax to end the comment sections. i18n.c:11:17: warning: "/*" within comment i18n.c:35:17: warning: "/*" within comment i18n.c:59:17: warning: "/*" within comment i18n.c:83:17: warning: "/*" within comment i18n.c:107:17: warning: "/*" within comment i18n.c:131:17: warning: "/*" within comment i18n.c:155:17: warning: "/*" within comment i18n.c:227:17: warning: "/*" within comment i18n.c:251:17: warning: "/*" within comment i18n.c:275:17: warning: "/*" within comment i18n.c:299:17: warning: "/*" within comment i18n.c:323:17: warning: "/*" within comment i18n.c:347:17: warning: "/*" within comment i18n.c:371:17: warning: "/*" within comment i18n.c:395:17: warning: "/*" within comment i18n.c:419:17: warning: "/*" within comment i18n.c:443:17: warning: "/*" within comment i18n.c:468:17: warning: "/*" within comment i18n.c:493:17: warning: "/*" within comment i18n.c:543:17: warning: "/*" within comment The attached patch fixes it. Best Regards. --- eggtimer-0.9.5/i18n.c.orig 2006-09-28 08:46:26.0 -0700 +++ eggtimer-0.9.5/i18n.c 2006-09-28 08:54:38.0 -0700 @@ -7,7 +7,7 @@ "Eieruhr", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Eierwekker", /*Nederlands* +"Eierwekker", /*Nederlands*/ "", // TODO /*Português*/ "Programmateur", /*Français*/ "", // TODO /*Norsk*/ @@ -31,7 +31,7 @@ "Eieruhr für VDR", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Eierwekker voor VDR", /*Nederlands* +"Eierwekker voor VDR", /*Nederlands*/ "", // TODO /*Português*/ "Programmateur pour VDR", /*Français*/ "", // TODO /*Norsk*/ @@ -55,7 +55,7 @@ "Eieruhr: Zeit ist abgelaufen", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Eierwekker: tijd is afgelopen", /*Nederlands* +"Eierwekker: tijd is afgelopen", /*Nederlands*/ "", // TODO /*Português*/ "Programmateur: le temps est écoulé", /*Français*/ "", // TODO /*Norsk*/ @@ -79,7 +79,7 @@ "Eieruhr ausschalten", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Stop eierwekker", /*Nederlands* +"Stop eierwekker", /*Nederlands*/ "", // TODO /*Português*/ "Arrêter le programmateur", /*Français*/ "", // TODO /*Norsk*/ @@ -103,7 +103,7 @@ "Vorlage", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Voorgave", /*Nederlands* +"Voorgave", /*Nederlands*/ "", // TODO /*Português*/ "Modèle", /*Français*/ "", // TODO /*Norsk*/ @@ -127,7 +127,7 @@ "Nachricht im OSD", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"OSD bericht", /*Nederlands* +"OSD bericht", /*Nederlands*/ "", // TODO /*Português*/ "Message OSD", /*Français*/ "", // TODO /*Norsk*/ @@ -151,7 +151,7 @@ "Umschalten", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Verwissel kanaal", /*Nederlands* +"Verwissel kanaal", /*Nederlands*/ "", // TODO /*Português*/ "Changer de chaine", /*Français*/ "", // TODO /*Norsk*/ @@ -175,7 +175,7 @@ "Eieruhr stellen", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Stel eierwekker in", // TODO /*Nederlands* +"Stel eierwekker in", // TODO /*Nederlands*/ "", // TODO /*Português*/ "Valider programmateur", /*Français*/ "", // TODO /*Norsk*/ @@ -199,7 +199,7 @@ "Aktion", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Aktie", // TODO /*Nederlands* +"Aktie", // TODO /*Nederlands*/ "", // TODO /*Português*/ "Action", /*Français*/ "", // TODO /*Norsk*/ @@ -223,7 +223,7 @@ "Abbrechen", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Afbreken", /*Nederlands* +"Afbreken", /*Nederlands*/ "", // TODO /*Português*/ "Annuler", /*Français*/ "", // TODO /*Norsk*/ @@ -247,7 +247,7 @@ "Zeit-Modus", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Tijd-modus", /*Nederlands* +"Tijd-modus", /*Nederlands*/ "", // TODO /*Português*/ "Echelle de temps", /*Français*/ "", // TODO /*Norsk*/ @@ -271,7 +271,7 @@ "Sekunden", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italiano*/ -"Seconden", /*Nederlands* +"Seconden", /*Nederlands*/ "", // TODO /*Português*/ "Secondes", /*Français*/ "", // TODO /*Norsk*/ @@ -295,7 +295,7 @@ " Sekunden", /*Deutsch*/ "", // TODO /*Slovenski*/ "", // TODO /*Italia
Re: [vdr] multiple keypresses with remote plugin
Oliver Endriss wrote: > Torgeir Veimo wrote: >> On 21 Sep 2006, at 09:03, Marko Mäkelä wrote: >> >>> On Sun, Sep 17, 2006 at 11:43:09AM +0100, Torgeir Veimo wrote: Using the remote plugin with a /dev/input/eventX setup for a hauppauge grey remote via a nova-t sensor with X11/Xv using softdevice works perfectly. With the same setup with directfb single button presses very often are detected as multiple button presses. >>> I don't remember seeing a reply to this. What does "evtest" report >>> when you press a button? >> It appears to be correct, it's just too fast, see below > > Please post the output of evtest for > - a single (short) keypress > - a long keypress I have the same problem using a nexus-s ir sensor and the grey remote with lirc. Evtest seems to show the right output, but lirc detects double key presses. If I set the toggle_bit in lircd.conf to "2", then I do not get double key presses with lirc, but the key repeat is then disabled permanently. If I use "inputlirc" instead of regular "lirc", then the key presses work as expected. Unfortunately, vdr does not seem to work with inputlirc. It would be nice to get lirc to function properly when accessing /dev/input/eventX when using a hauppauge remote and ir sensor. When I build lirc, I configure it with "--with-driver=devinput". BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MP3/MPlayer plugin 0.9.15 available
> - Added -S option to ppmtoy4m call in example image convert script. Suggested > by > Thorsten Gehrig. I was thinking of something more like this for backwards compatibility: @@ -61,17 +61,23 @@ # # now run the conversion # + +# 'chroma subsampling mode' mjpegtools >= 1.8.0 +if ppmtoy4m -h | egrep -q "'420mpeg2'" ; then +SUBSAMPLINGMODE="-S 420mpeg2" +fi + if [ "$FORMAT" = "ntsc" ]; then pnmscale $S $TMP | \ pnmpad -black -width 704 -height 480 | \ ppmntsc | \ -ppmtoy4m -S 420mpeg2 -v 0 -n 1 -r -F 3:1001 | \ +ppmtoy4m -v 0 -n 1 -r -F 3:1001 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 4 -nn -a 2 -v 0 -o "$MPG" else pnmscale $S $TMP | \ pnmpad -black -width 704 -height 576 | \ ppmntsc --pal | \ -ppmtoy4m -S 420mpeg2 -v 0 -n 1 -r -F 25:1 | \ +ppmtoy4m -v 0 -n 1 -r -F 25:1 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 3 -np -a 2 -v 0 -o "$MPG" fi # Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] execute command after vdr starts
Udo Richter wrote:
> C.Y.M wrote:
>> Yes, I like the idea of backgrounding VDR using "&" and then using
>> 'wait $PID'.
>> Is that the method you use? I've been trying to find the best way to
>> do this.
>> Could you give me an example? :)
>
> Something like that. This is a snippet of my overgrown runvdr script:
>
> # Run VDR
> eval "$VDRCMD &"
>
> # Remember PID of VDR process
> PID=$!
>
> # Wait for VDR to end or signal to arrive
> wait $PID
>
> # Remember return value of VDR
> RET=$?
>
> The reason I do it this way is that I also handle some signals sent to
> runvdr, to terminate or restart on demand.
> If you want to start something in parallel, its probably no big
> difference whether you start your script before or after VDR, as long as
> you background it. You can background within a script like this:
>
> {
> sleep 1s
> echo -n world
> } &
> echo -n "hello "
> sleep 2s
> echo .
>
>> For now, I'm just trying to send a MESG via svdrpsend.pl to VDR so it
>> displays a
>> welcome message after starting up and initializing its plugins.
>
> You can wait for the SVDRP socket to accept connections, that would be
> one way to wait for a mainly running VDR.
>
Thanks a lot Udo. Those examples really helped. Here is what I have done...
BR.
#!/bin/sh
# insmod modules from current directory without having to install them first
# KERNELVER=`uname -r`
# KERNELDIR="/lib/modules/$KERNELVER/misc"
sync
function DriverLoaded()
{
grep -qse dvb[-_]core /proc/modules
}
DEVTIMEOUT=10
LOOP=0
case "$1" in
load)
if ! DriverLoaded; then
echo -e "Inserting DVB modules into kernel. \n"
# STARTTIME=$(date +%s)
# av7110 based "full featured" cards
modprobe stv0299
# saa7146 based siemens/technotrend/hauppauge cards
modprobe dvb-ttpci
# wait for udev to create the devices before continuing
until [ -e /dev/dvb/adapter0/video0 ] || [ $LOOP -eq $DEVTIMEOUT ] ; do
sleep 1
LOOP=$((LOOP+1))
done
if [ $LOOP -eq $DEVTIMEOUT ]; then
echo -e "Creation of /dev/dvb/adapter0/video0 has timed out in
$DEVTIMEOUT seconds. Check UDEV or rebuild drivers. \n"
exit 1
fi
# FINISHTIME=$(date +%s)
# RESULTTIME=$((FINISHTIME - STARTTIME))
# echo -e "DVB device created in $RESULTTIME second(s). \n"
if [ -e "/usr/local/bin/loadkeys/av7110_loadkeys" ]; then
/usr/local/bin/loadkeys/av7110_loadkeys
/usr/local/bin/loadkeys/hauppauge_grey.rc5 > /proc/av7110_ir
sleep 1
fi
else
echo -e "DVB Drivers already loaded. \n"
fi
;;
debug)
if ! DriverLoaded; then
echo -e "Inserting DVB modules (debug) into kernel. \n"
# STARTTIME=$(date +%s)
# av7110 based "full featured" cards
modprobe stv0299 debug_switch_timing=1
# saa7146 based siemens/technotrend/hauppauge cards
modprobe dvb-ttpci debug=247
until [ -e /dev/dvb/adapter0/video0 ] || [ $LOOP -eq $DEVTIMEOUT ] ; do
sleep 1
LOOP=$((LOOP+1))
done
if [ $LOOP -eq $DEVTIMEOUT ]; then
echo -e "Creation of /dev/dvb/adapter0/video0 has timed out in
$DEVTIMEOUT seconds. Check UDEV or rebuild drivers. \n"
exit 1
fi
# FINISHTIME=$(date +%s)
# RESULTTIME=$((FINISHTIME - STARTTIME))
# echo -e "DVB device created in $RESULTTIME second(s). \n"
if [ -e "/usr/local/bin/loadkeys/av7110_loadkeys" ]; then
/usr/local/bin/loadkeys/av7110_loadkeys
/usr/local/bin/loadkeys/hauppauge_grey.rc5 > /proc/av7110_ir
sleep 1
fi
else
echo -e "DVB Drivers already loaded. \n"
fi
;;
unload)
if DriverLoaded; then
echo -e "Removing DVB modules from kernel. \n"
rmmod ves1x93 dvb_ttpci saa7146_vv video_buf saa7146 videodev
v4l1_compat \
v4l2_common ttpci_eeprom stv0299 dvb_core
echo
else
echo -e "DVB Drivers not loaded. \n"
fi
;;
reload)
$0 unload && $0 load
;;
*)
echo "Usage$0 {load|unload|debug|reload}"
exit 1
esac
sync
#!/bin/sh
# runvdr: Loads the DVB driver and runs VDR
#
# If VDR exits abnormally, the driver will be reloaded
# and VDR restarted.
#
# In order to actually use this script you need to implement
# the functions DriverLoaded(), LoadDriver() and UnloadDriver()
# and maybe adjust the VDRPRG and VDRCMD to your part
Re: AW: [vdr] execute command after vdr starts
Udo Richter wrote: > C.Y.M wrote: >> Because in the runvdr script, the vdr command is executed by an "eval" >> statement >> which basically waits for the process to die before it continues on. > > This could be avoided by backgrounding VDR, do other stuff, and then > 'wait' for VDR to terminante. 'wait $PID' will even return the error > level of VDR. Yes, I like the idea of backgrounding VDR using "&" and then using 'wait $PID'. Is that the method you use? I've been trying to find the best way to do this. Could you give me an example? :) > >> This is how the script makes vdr will restart automatically when it >> crashes. I'm >> looking for a way to have vdr execute the command so I dont have to >> guess with >> sleep statements. > > So you actually want to start your process some time *after* VDR started > up, so that VDR has initialized some stuff. So for what are you waiting > actually? Reading configuration? Loading plugins? Starting pending > timers? Updating EPG? > For now, I'm just trying to send a MESG via svdrpsend.pl to VDR so it displays a welcome message after starting up and initializing its plugins. But, I might also want VDR to send me an email when it restarts. Its hard to time it properly if I call runvdr with an init.d script and send runvdr in the background. Since runvdr will load the drivers, call up a startup video, then wait for vdr to initialize all its plugins before trying to send a welcome message to the OSD via svdrpsend. The idea of 'wait $PID' sounds good, but there would still need to be a sleep after starting vdr as a background process (since plugins must initialize). Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] execute command after vdr starts
Udo Richter wrote: > C.Y.M wrote: >> Thanks for your replay, but I was looking for a switch that would make >> vdr run a >> script right after vdr starts up. > > If you want to start a program together with VDR, why don't you put it > into your runvdr script? > Because in the runvdr script, the vdr command is executed by an "eval" statement which basically waits for the process to die before it continues on. eval "$VDRCMD" if test $? -eq 0 -o $? -eq 2; then exit; fi echo "`date` Reloading DVB drivers" ... This is how the script makes vdr will restart automatically when it crashes. I'm looking for a way to have vdr execute the command so I dont have to guess with sleep statements. BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] execute command after vdr starts
martin wrote: > Just add option "-r script.sh" > > #!/bin/sh > case "$1" in > before) > ;; > after) > echo "After recording $2" > /usr/local/bin/startnoad.sh "$2" & > ;; > edited) > echo "Edited recording $2" > ;; > *) > echo "ERROR: unknown state: $1" > ;; > esac > Thanks for your replay, but I was looking for a switch that would make vdr run a script right after vdr starts up. Can this be adopted to that? This seems to only work after a recording has occurred. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] changes to runvdr for a nexus-s
Here is an example of the changes that I have had to make to runvdr so that my
nexus-s works. I have added a maximum retry value to runvdr so that vdr will
not keep attempting to start over and over if there is a major problem with
reception. Also, I have added a minimum runtime (in seconds) that vdr must have
in order to continue attempting to restart after a crash. For example, if vdr
crashes within 10 seconds and the minimum runtime required is 45 seconds, then
runvdr will consider that VDR has major problems and it will not try to keep
restarting up to the maximum allowed retries. However, the maximum retry value
can be set to "0" which would tell runvdr to attempt a restart unlimited times
after crashing.
BR.
--- vdr-1.4.2/runvdr.orig 2006-09-05 06:30:55.0 -0700
+++ vdr-1.4.2/runvdr 2006-09-05 06:31:37.0 -0700
@@ -22,26 +22,72 @@
#
# $Id: runvdr 1.19 2006/05/14 16:02:05 kls Exp $
-VDRPRG="./vdr"
-VDRCMD="$VDRPRG -w 60 $*"
+## Start Configuration Section ##
+# Disable NPTL (recommended)
+export LD_ASSUME_KERNEL=2.4.1
+#export LD_ASSUME_KERNEL=2.4.19
+
+# Uncomment to disable UTF-8 within VDR
+#export LANG=en_US
+#export LC_CTYPE=iso_8859_1
+
+PLUGINS="-Premote -Pscreenshot -Pepgsearch -Pprefermenu -Pdvdselect -Pvcd -Pfemon -Ptaste -Pstreamdev-server -Pstreamplayer -Ptext2skin -Pyaepg -Pundelete -Pweatherng -Posdpip -Pmplayercluster -Peggtimer -Psysinfo -Plocals -Pradioinfo -P'mp3 -C /etc/vdr -m /etc/vdr/plugins/mount.sh -i /etc/vdr/plugins/image_convert.sh -c /etc/vdr/images' -P'dvd -C/dev/cdrom' -P'mplayer -M /etc/vdr/plugins/mplayer.sh -m /etc/vdr/plugins/mount.sh' -P'xine -r -X 720 -Y 480'"
+
+# VDR Recording directory (default is usually /video)
+VIDEO_DIR="/video"
+# VDR Configuration directory where setup.conf lives
+CFG_DIR="/etc/vdr"
+# Where the VDR epg.data file lives
+EPG_DIR="/etc/vdr"
+# Search path for VDR plugins
+PLUG_DIR="/usr/local/bin/PLUGINS/lib"
+# Startup Options passed to VDR
+OPTIONS="--terminal=/dev/tty8 -l 3 -w 0 --grab=/tmp"
+# Path to VDR binary
+VDRPRG="/usr/local/bin/vdr"
+# Path to insdvb.sh (for loading dvb modules)
+INSDVB="/usr/local/bin/insdvb.sh"
+# Path to mplayer
+MPLAY="/usr/bin/mplayer"
+# Path to startup video
+VIDEO="/etc/vdr/VDRboot-NTSC.mpeg"
+# Number of times runvdr will attempt to restart vdr after a crash has occured (set to 0 for no limit)
+MAXTRIES=10
+# Minimum runtime required (in seconds) for vdr to continue restart attempts
+MINRUN=45
+
+## End Configuration Section ##
+
+if [ ! -e "${INSDVB}" ]; then
+ echo -e "ERROR: ${INSDVB} was not detected. Exiting. \n"
+ exit 0
+fi
+
+VDRCMD="$VDRPRG -v $VIDEO_DIR -E $EPG_DIR -c $CFG_DIR -L $PLUG_DIR $OPTIONS $PLUGINS"
KILL="/usr/bin/killall -q -TERM"
# Detect whether the DVB driver is already loaded
# and return 0 if it *is* loaded, 1 if not:
function DriverLoaded()
{
- return 1
+ grep -qse dvb[-_]core /proc/modules
}
# Load all DVB driver modules needed for your hardware:
function LoadDriver()
{
+ ${INSDVB} load
+ if [ -e "${MPLAY}" ]; then
+${MPLAY} -frames 145 -vo mpegpes -ao mpegpes ${VIDEO} 2>/dev/null 1>/dev/null
+ fi
+ echo
}
# Unload all DVB driver modules loaded in LoadDriver():
function UnloadDriver()
{
+ ${INSDVB} unload
}
# Load driver if it hasn't been loaded already:
@@ -49,13 +95,26 @@
LoadDriver
fi
+LASTRESTART=$(date +%s)
+LOOPCOUNT=0
while (true) do
- eval "$VDRCMD"
+ if [ $LOOPCOUNT -le $MAXTRIES ] || [ $MAXTRIES -eq 0 ] ; then
+eval "$VDRCMD"
+ else
+$KILL runvdr
+ fi
if test $? -eq 0 -o $? -eq 2; then exit; fi
- echo "`date` reloading DVB driver"
- $KILL $VDRPRG
+ TIMEOFDEATH=$(date +%s)
+ if [ $TIMEOFDEATH -le $(($LASTRESTART + $MINRUN)) ] ; then
+echo "`date` VDR crashed in `expr $TIMEOFDEATH - $LASTRESTART` seconds. Minimum required runtime for VDR is $MINRUN seconds. Killing runvdr process..."
+$KILL runvdr
+ fi
+ echo "`date` Reloading DVB drivers"
+ $KILL vdr
sleep 10
UnloadDriver
LoadDriver
- echo "`date` restarting VDR"
+ LASTRESTART=$(date +%s)
+ LOOPCOUNT=`expr $LOOPCOUNT + 1`
+ echo "`date` Restarting VDR $LOOPCOUNT time(s). Maximum retries set to $MAXTRIES"
done
#!/bin/sh
# insmod modules from current directory without having to install them first
# KERNELVER=`uname -r`
# KERNELDIR="/lib/modules/$KERNELVER/misc"
sync
function DriverLoaded()
{
grep -qse dvb[-_]core /proc/modules
}
case "$1" in
load)
if ! DriverLoaded; then
echo -n -e "\nInserting DVB modules into kernel\n"
# av7110 based "full featured" cards
modprobe stv0299
# saa7146 based siemens/technotrend/hauppauge cards
modprobe dvb-ttpci
# wait for udev to create the devices before continuing
until [ -e /dev/dvb/adapter0/video0 ]; do
sleep 1
done
if [ -e "/usr/local/bin/loadkeys/av7110_loadkeys" ]; then
[vdr] execute command after vdr starts
Is there a command line switch that would allow me to define a command vdr must excute after initial startup? I see one for before and after recordings, but I am looking for a way to execute a command after startup only. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] sofdevice cvs unused variables
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to build
under the latest VDR.
Best Regards,
--- softdevice.cvs/video-shm.c.orig 2006-09-03 04:34:56.0 -0700
+++ softdevice.cvs/video-shm.c 2006-09-03 04:41:00.0 -0700
@@ -285,16 +285,16 @@
};
void cShmVideoOut::YUV(sPicBuffer *buf) {
-uint8_t *Py=buf->pixel[0]+(buf->edge_height)*buf->stride[0]
-+buf->edge_width;
-uint8_t *Pu=buf->pixel[1]+(buf->edge_height/2)*buf->stride[1]
-+buf->edge_width/2;
-uint8_t *Pv=buf->pixel[2]+(buf->edge_height/2)*buf->stride[2]
-+buf->edge_width/2;
-int Ystride=buf->stride[0];
-int UVstride=buf->stride[1];
-int Width=buf->width;
-int Height=buf->height;
+//uint8_t *Py=buf->pixel[0]+(buf->edge_height)*buf->stride[0]
+//+buf->edge_width;
+//uint8_t *Pu=buf->pixel[1]+(buf->edge_height/2)*buf->stride[1]
+//+buf->edge_width/2;
+//uint8_t *Pv=buf->pixel[2]+(buf->edge_height/2)*buf->stride[2]
+//+buf->edge_width/2;
+//int Ystride=buf->stride[0];
+//int UVstride=buf->stride[1];
+//int Width=buf->width;
+//int Height=buf->height;
if (!ctl->attached) {
setupStore->shouldSuspend=1;
@@ -354,8 +354,8 @@
return;
};
-int width= ctl->max_width < Width ? ctl->max_width : Width;
-int height= ctl->max_height < Height ? ctl->max_height : Height;
+//int width= ctl->max_width < Width ? ctl->max_width : Width;
+//int height= ctl->max_height < Height ? ctl->max_height : Height;
ctl->width=fwidth;
ctl->height=fheight;
--- softdevice.cvs/video-xv.c.orig 2006-09-03 04:35:18.0 -0700
+++ softdevice.cvs/video-xv.c 2006-09-03 04:36:34.0 -0700
@@ -1814,10 +1814,10 @@
+buf->edge_width/2;
uint8_t *Pv=buf->pixel[2]+(buf->edge_height/2)*buf->stride[2]
+buf->edge_width/2;
- int Ystride=buf->stride[0];
- int UVstride=buf->stride[1];
- int Width=buf->width;
- int Height=buf->height;
+// int Ystride=buf->stride[0];
+// int UVstride=buf->stride[1];
+// int Width=buf->width;
+// int Height=buf->height;
if ( Py && Pu && Pv ) {
#if VDRVERSNUM >= 10307
--- softplay.cvs/Makefile.orig 2006-05-19 01:04:59.0 -0700
+++ softplay.cvs/Makefile 2006-05-19 01:05:35.0 -0700
@@ -90,4 +90,4 @@
@echo Distribution package created as $(PACKAGE).tgz
clean:
- @-rm -f $(OBJS) $(DEPFILE) *.so *.tgz core* *~
+ @-rm -f $(OBJS) $(DEPFILE) *.so *.tgz core* *~ getFFmpegLibs
diff -ru softplay.cvs.orig/Makefile softplay.cvs/Makefile
--- softplay.cvs.orig/Makefile 2006-04-26 00:29:15.0 -0700
+++ softplay.cvs/Makefile 2006-04-26 00:59:27.0 -0700
@@ -24,7 +24,6 @@
### The directory environment:
-DVBDIR = ../../../../DVB
VDRDIR = ../../..
LIBDIR = ../../lib
TMPDIR = /tmp
@@ -35,7 +34,11 @@
### The version number of VDR (taken from VDR's "config.h"):
-VDRVERSION = $(shell grep 'define VDRVERSION ' $(VDRDIR)/config.h | awk '{ print $$3 }' | sed -e 's/"//g')
+VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*"\(.*\)".*$$/\1/p' $(VDRDIR)/config.h)
+APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*"\(.*\)".*$$/\1/p' $(VDRDIR)/config.h)
+ifeq ($(strip $(APIVERSION)),)
+ APIVERSION = $(VDRVERSION)
+endif
### The name of the distribution archive:
@@ -44,7 +47,7 @@
### Includes and Defines (add further entries here):
-INCLUDES += -I$(VDRDIR)/include -I$(DVBDIR)/include -I$(LIBFFMPEG) -I$(LIBFFMPEG)/libavformat -I$(LIBFFMPEG)/libavcodec -I$(LIBFFMPEG)/libavutil
+INCLUDES += -I$(VDRDIR)/include -I$(LIBFFMPEG) -I$(LIBFFMPEG)/libavformat -I$(LIBFFMPEG)/libavcodec -I$(LIBFFMPEG)/libavutil
DEFINES += -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"$(PLUGIN)"'
@@ -79,7 +82,7 @@
libvdr-$(PLUGIN).so: $(OBJS)
$(CXX) $(CXXFLAGS) -shared $(OBJS) $(LIBS) -o $@
- @cp $@ $(LIBDIR)/[EMAIL PROTECTED](VDRVERSION)
+ @cp $@ $(LIBDIR)/[EMAIL PROTECTED](APIVERSION)
dist: clean
@-rm -rf $(TMPDIR)/$(ARCHIVE)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sofdevice and softplay cvs cleanups
C.Y.M wrote:
> I have been trying to clean up my builds and when updated softdevice and
> softplay via cvs, noticed several warning about unused variables. Also, it
> appears that softplay does not have the current Makefile fixes required to
> build
> under the latest VDR.
>
And this one too..
BR.
diff -ru softplay.cvs.orig/Makefile softplay.cvs/Makefile
--- softplay.cvs.orig/Makefile 2006-04-26 00:29:15.0 -0700
+++ softplay.cvs/Makefile 2006-04-26 00:59:27.0 -0700
@@ -24,7 +24,6 @@
### The directory environment:
-DVBDIR = ../../../../DVB
VDRDIR = ../../..
LIBDIR = ../../lib
TMPDIR = /tmp
@@ -35,7 +34,11 @@
### The version number of VDR (taken from VDR's "config.h"):
-VDRVERSION = $(shell grep 'define VDRVERSION ' $(VDRDIR)/config.h | awk '{ print $$3 }' | sed -e 's/"//g')
+VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*"\(.*\)".*$$/\1/p' $(VDRDIR)/config.h)
+APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*"\(.*\)".*$$/\1/p' $(VDRDIR)/config.h)
+ifeq ($(strip $(APIVERSION)),)
+ APIVERSION = $(VDRVERSION)
+endif
### The name of the distribution archive:
@@ -44,7 +47,7 @@
### Includes and Defines (add further entries here):
-INCLUDES += -I$(VDRDIR)/include -I$(DVBDIR)/include -I$(LIBFFMPEG) -I$(LIBFFMPEG)/libavformat -I$(LIBFFMPEG)/libavcodec -I$(LIBFFMPEG)/libavutil
+INCLUDES += -I$(VDRDIR)/include -I$(LIBFFMPEG) -I$(LIBFFMPEG)/libavformat -I$(LIBFFMPEG)/libavcodec -I$(LIBFFMPEG)/libavutil
DEFINES += -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"$(PLUGIN)"'
@@ -79,7 +82,7 @@
libvdr-$(PLUGIN).so: $(OBJS)
$(CXX) $(CXXFLAGS) -shared $(OBJS) $(LIBS) -o $@
- @cp $@ $(LIBDIR)/[EMAIL PROTECTED](VDRVERSION)
+ @cp $@ $(LIBDIR)/[EMAIL PROTECTED](APIVERSION)
dist: clean
@-rm -rf $(TMPDIR)/$(ARCHIVE)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] sofdevice and softplay cvs cleanups
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to build
under the latest VDR.
Best Regards,
--- softdevice.cvs/video-shm.c.orig 2006-09-03 04:34:56.0 -0700
+++ softdevice.cvs/video-shm.c 2006-09-03 04:41:00.0 -0700
@@ -285,16 +285,16 @@
};
void cShmVideoOut::YUV(sPicBuffer *buf) {
-uint8_t *Py=buf->pixel[0]+(buf->edge_height)*buf->stride[0]
-+buf->edge_width;
-uint8_t *Pu=buf->pixel[1]+(buf->edge_height/2)*buf->stride[1]
-+buf->edge_width/2;
-uint8_t *Pv=buf->pixel[2]+(buf->edge_height/2)*buf->stride[2]
-+buf->edge_width/2;
-int Ystride=buf->stride[0];
-int UVstride=buf->stride[1];
-int Width=buf->width;
-int Height=buf->height;
+//uint8_t *Py=buf->pixel[0]+(buf->edge_height)*buf->stride[0]
+//+buf->edge_width;
+//uint8_t *Pu=buf->pixel[1]+(buf->edge_height/2)*buf->stride[1]
+//+buf->edge_width/2;
+//uint8_t *Pv=buf->pixel[2]+(buf->edge_height/2)*buf->stride[2]
+//+buf->edge_width/2;
+//int Ystride=buf->stride[0];
+//int UVstride=buf->stride[1];
+//int Width=buf->width;
+//int Height=buf->height;
if (!ctl->attached) {
setupStore->shouldSuspend=1;
@@ -354,8 +354,8 @@
return;
};
-int width= ctl->max_width < Width ? ctl->max_width : Width;
-int height= ctl->max_height < Height ? ctl->max_height : Height;
+//int width= ctl->max_width < Width ? ctl->max_width : Width;
+//int height= ctl->max_height < Height ? ctl->max_height : Height;
ctl->width=fwidth;
ctl->height=fheight;
--- softdevice.cvs/video-xv.c.orig 2006-09-03 04:35:18.0 -0700
+++ softdevice.cvs/video-xv.c 2006-09-03 04:36:34.0 -0700
@@ -1814,10 +1814,10 @@
+buf->edge_width/2;
uint8_t *Pv=buf->pixel[2]+(buf->edge_height/2)*buf->stride[2]
+buf->edge_width/2;
- int Ystride=buf->stride[0];
- int UVstride=buf->stride[1];
- int Width=buf->width;
- int Height=buf->height;
+// int Ystride=buf->stride[0];
+// int UVstride=buf->stride[1];
+// int Width=buf->width;
+// int Height=buf->height;
if ( Py && Pu && Pv ) {
#if VDRVERSNUM >= 10307
--- softplay.cvs/Makefile.orig 2006-05-19 01:04:59.0 -0700
+++ softplay.cvs/Makefile 2006-05-19 01:05:35.0 -0700
@@ -90,4 +90,4 @@
@echo Distribution package created as $(PACKAGE).tgz
clean:
- @-rm -f $(OBJS) $(DEPFILE) *.so *.tgz core* *~
+ @-rm -f $(OBJS) $(DEPFILE) *.so *.tgz core* *~ getFFmpegLibs
diff -ru softplay/Makefile softplay.cvs/Makefile
--- softplay/Makefile.orig 2006-03-20 12:09:20.0 -0800
+++ softplay/Makefile 2006-04-01 18:22:00.0 -0800
@@ -11,7 +11,7 @@
#LIBFFMPEG=/home/martin/vdr/ffmpeg
#LIBFFMPEG=/home/martin/vdr/ffmpeg-0.4.9-pre1
-LIBFFMPEG=/usr/local/include/ffmpeg/
+LIBFFMPEG=/usr/include/ffmpeg/
### The version number of this plugin (taken from the main source file):
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] unused variable in liemikuutio-1.10
Hello,
I just wanted to mention that I noticed a warning when compiling the latest
liemikuutio-1.10 patch with an unused variable.
Best Regards.
--- vdr-1.4.2/recording.c.orig 2006-08-27 20:46:51.0 -0700
+++ vdr-1.4.2/recording.c 2006-08-27 20:47:40.0 -0700
@@ -736,7 +736,7 @@
char RecLength[5], RecDate[9], RecTime[6], RecDelimiter[2];
snprintf(RecLength, sizeof(RecLength), "---");
if (Setup.ShowRecLength && FileName()) {
- struct stat buf;
+// struct stat buf;
char *filename = NULL;
asprintf(&filename, "%s%s", FileName(), INDEXFILESUFFIX);
if (filename) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib.cvs Compile stop errors
Darren Salt wrote: > I demand that Stone may or may not have written... > >>> There is a fixed patchset here: >>> http://www.youmustbejoking.demon.co.uk/patches/vdr-xine/> > >> Darren, should all of these patches in your vdr-xine directory be applied >> to current xine development? Thanks for the patches. > > Eventually. I won't commit them without being told that they're ready for > commit and, ideally, not before they've been reviewed. > Darren, has the xine-lib_modify_expand_plugin.patch been integrated to cvs now? Seems to cause an error. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
