Re: [vdr] Problem with two cards
Teemu Suikki wrote: Perhaps there is some problem having tda10045 and tda10046 in same system? After all, both are handled by the same tda1004x module.. The dmesg output does not look suspicious at all. It seems as if both cards have been registered successfully. The only thing you can do, (that I can think of right now) was to write to the linux-dvb list and ask the developers there if they have ever tested this particular setup and if it could cause problems. André ___ 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] FF card AV sync problems, possible fix to VDR (fwd)
Ville Rannikko kirjoitti: Hi! The newest firmware for FF cards did not completely fix the AV desync problems for me. Can you provide a sample recording where A/V sync fails with the current firmware? Oh, well. Turns out that I had somehow failed to install the new firmware properly. My test patch is possibly not needed at all. I still have experienced AV sync problem with the new fw. The problem is that I can not reproduce the problem. Replaying the video again does not usually give the same result. The sync problem I've experienced with this new fw is just a slight out of sync, less than half a second, but it is noticeable. I can not really say yet how the problem occurs, what are the circumstances. I must check if pausing or jumping causes it or is it something changes in the video. Its nowadays so rare :) I was so used to have it :) \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: replay stuttering
Kartsa kirjoitti: I have been running vdr now for a couple days with #define PLAYERBUFSIZE MEGABYTE(64) in dvbplayer.c and for now it seems like better as in no stuttering. But I am still testing it. Okey, I've had this setting in action for a week or so now and it is definitely better. There is still sometimes some stuttering but it is so suttle that it is barely noticeable. With MEGABYTE(1) the video occasionally stopped for a second and then stuttered for about 5 seconds and then resumed normal operation (with lesser cpu it could be stuttering to the end of the recording). Could the chosen file system be causing this? I use LVM creating one partition on two disks and then I create one xfs on that partition. The disks are sata as mentioned earlier. \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: replay stuttering
Kartsa wrote: Kartsa kirjoitti: I have been running vdr now for a couple days with #define PLAYERBUFSIZE MEGABYTE(64) in dvbplayer.c and for now it seems like better as in no stuttering. But I am still testing it. Okey, I've had this setting in action for a week or so now and it is definitely better. There is still sometimes some stuttering but it is so suttle that it is barely noticeable. With MEGABYTE(1) the video occasionally stopped for a second and then stuttered for about 5 seconds and then resumed normal operation (with lesser cpu it could be stuttering to the end of the recording). As mentioned earlier in this thread, I had also sometimes noticed a similar effect video halts for a few seconds, then resumes and stutters for a few seconds. After recommending it to you, I have also increased PLAYERBUFSIZE to 64MB and I have not noticed the problem ever since. So there is a high probability that increasing PLAYERBUFSIZE improves matters. Maybe it should not be fixed, though, since a machine with very little RAM may suffer from thrashing if the VDR footprint is increased that much. I wonder if it should be configurable or if there would be an automatic way of determining the right size (i.e. start with 1 MB, then double it on every stutter and remember the value in the setup.conf file). Could the chosen file system be causing this? I use LVM creating one partition on two disks and then I create one xfs on that partition. The disks are sata as mentioned earlier. I do not think so. Maybe S.M.A.R.T., maybe hardware, but not the file system. I am using XFS on individual (mostly PATA) disks over NFS. Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Vdr or driver performance dropout
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Is this vdr related or firmware related. After all the error is fw error isn't it? \\Kartsa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with two cards
I demand that Teemu Suikki may or may not have written... Hi, I have been using VDR for about two years now, without any big problems. :) Now I built a new system with two cards. One is my old hauppaude nova-t, other is technotrend nova-t with CI.. [snip] What has this to do with the shutdown rewrite? (Hint: new thread, not followup or reply.) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. It is easier to suggest solutions when you know nothing about the problem. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On to, 2007-02-01 at 19:29 +0200, Kartsa wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Blocking the playback of recordings in plugins
Hi, Marko Mäkelä wrote: I believe that the easy fix would be to have these methods return 0 only when playing a recording. Can the plugin detect this somehow? For live TV, VDR runs a transfer thread and the replaying device may use cDevice::Transferring() to detect this (works at least for vdr-xine in cXineDevice::SetPlayMode() for PlayMode being != pmNone). Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Hi, Heikki Manninen wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: replay stuttering
I have noticed smilar trouble: When VDR playbacks a recording, and I pause playback and put play again, video starts playing, then stops for less than second after about 5 seconds, then plays, after two seconds stops again for one second, and then plays smoothly. I have noticed replay stuttering trouble sometimes, but increasing PLAYERBUFSIZE to MEGABYTE(8) resolved the trouble. Boguslaw Juza ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Blocking the playback of recordings in plugins
On Thu, Feb 01, 2007 at 07:57:20PM +0100, Reinhard Nissl wrote: Hi, Marko Mäkelä wrote: I believe that the easy fix would be to have these methods return 0 only when playing a recording. Can the plugin detect this somehow? For live TV, VDR runs a transfer thread and the replaying device may use cDevice::Transferring() to detect this (works at least for vdr-xine in cXineDevice::SetPlayMode() for PlayMode being != pmNone). Thanks, I knew there had to be some way. Softdevice used to blank the screen after a few seconds of missing video stream (tuned to an audio channel). A fix was introduced so that it wouldn't blank the screen when a recording was paused. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote: Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame. Mrako ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Reinhard Nissl kirjoitti: Hi, Heikki Manninen wrote: I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly. Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area. Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. \\Kartsa ___ 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 Thu, Feb 01, 2007 at 08:27:14PM +0200, Marko Mäkelä wrote: Maybe not switching off display while doing playback? It doesn't make much sense anyway to run playback invisible. It does. The typical use case is that you pause live video or start a recording with a timer, then start watching it while it is still recording, so that you can skip commercial breaks. Then you get interrupted while watching it. It would be very handy to push the power button. If it was a short interruption, you'd push any button to resume playback. If the interruption was longer (such as your kid wakes up and you'll have to put him back to sleep for a few hours), vdr would do the right thing and shut down after finishing the recording. According to Reinhard Nissl's reply in another thread, this can be fixed in the cDevice plugin by not blocking input in cDevice::PlayVideo() or cDevice::PlayAudio() when cDevice::Transferring() holds. I'll update my shutdown patch for softdevice soon. No need to change anything in your patch. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
In [EMAIL PROTECTED], you wrote: I wouldn't be so sure about the majority of VDRs using FF cards. I haven't seen any ad for an FF card, but I have seen many ads for cheap USB DVB-T tuners. The trend is likely to change, given that decoding MPEG-2 is no challenge to current PC hardware. Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that. -- TH * http://www.realh.co.uk ___ 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)
Ville Rannikko kirjoitti: Hi! The newest firmware for FF cards did not completely fix the AV desync problems for me. Can you provide a sample recording where A/V sync fails with the current firmware? I was just watching an Idols Extra recorded today and there were multiple out of sync situations that were allways fixed by a 10s backwards jump. I could not see anything in the picture (like periods of black etc.) that would cause this. To make the best of this I should make the whole recording available somewhere because I would not know what to take out of it. And that is not very convenient because of the size of the file. This is what was in the log if this is at all relevant. Feb 1 21:20:48 vdr: [2635] replay /srv/vdr/Idols_Extra/2007-02-01.20.59.50.99.rec Feb 1 21:20:59 vdr: [3955] 3 cRepacker messages suppressed Feb 1 21:20:59 vdr: [3955] cAudioRepacker(0xC0): skipped 134 bytes to sync on next audio frame Feb 1 21:22:09 vdr: [3955] 2 cRepacker messages suppressed Feb 1 21:22:09 vdr: [3955] cAudioRepacker(0xC0): skipped 68 bytes while syncing on next audio frame Feb 1 21:25:37 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:25:37 vdr: [3955] cAudioRepacker(0xC0): skipped 84 bytes to sync on next audio frame Feb 1 21:26:14 vdr: [3955] cAudioRepacker(0xC0): skipped 68 bytes to sync on next audio frame Feb 1 21:26:45 vdr: [3955] cAudioRepacker(0xC0): skipped 476 bytes while syncing on next audio frame Feb 1 21:32:45 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:32:45 vdr: [3955] cAudioRepacker(0xC0): skipped 502 bytes while syncing on next audio frame Feb 1 21:34:52 vdr: [3955] 1 cRepacker messages suppressed Feb 1 21:34:52 vdr: [3955] cAudioRepacker(0xC0): skipped 232 bytes while syncing on next audio frame Feb 1 21:36:55 vdr: [3955] 3 cRepacker messages suppressed Feb 1 21:36:55 vdr: [3955] cAudioRepacker(0xC0): skipped 54 bytes to sync on next audio frame Feb 1 21:38:06 vdr: [3955] 2 cRepacker messages suppressed Feb 1 21:38:06 vdr: [3955] cAudioRepacker(0xC0): skipped 468 bytes while syncing on next audio frame Feb 1 21:40:00 vdr: [2635] timer 22 (5 2059-2140 'Idols Extra') stop As you can see the recording was on the way as I was watching it. I've removed two channel events and one ntp event from the log output. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Marko Mäkelä kirjoitti: On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote: Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time. Bye. I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. ___ 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 wouldn't be so sure about the majority of VDRs using FF cards. I haven't seen any ad for an FF card, but I have seen many ads for cheap USB DVB-T tuners. The trend is likely to change, given that decoding MPEG-2 is no challenge to current PC hardware. Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that. Not to get too off-topic, but I disagree. In north america, from surveying posts on several bulletin boards, vdr usage seems to be 90%+ with FF cards (typically the Nexus-S). There's actually the perception with many in NA that vdr doesn't work with budget cards! And while more PCs are adding the built-in functions a FF card provides (Digital audio out, Coax or S-video out, adequate processing power for decoding) everything seems to be moving to mpeg-4. I know from working regularly with Xvid / mpeg4 files that they require a lot more processing power, and many pcs are older machines dedicated to running vdr, not top of the line full fledged 4 ghz systems. I've never regretted owning my FF card, and would look for a FF mpeg4 card if I was in the market. Plus, they always seem the simplest to configure and use with most software, not to mention not requiring a computer monitor to run vdr on FF :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote: Marko Mäkelä kirjoitti: I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings. You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources. In any case, you could profile the old and new version of vdr and see if there is any obvious difference. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Marko Mäkelä kirjoitti: On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote: Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish. Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources. In any case, you could profile the old and new version of vdr and see if there is any obvious difference. I'll have to take that into consideration. I'll have to download the old version and all that :) \\Kartsa ___ 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)
Reinhard Nissl kirjoitti:
If you can reproduce this behaviour, would you please activate the
following line in remux.c:
dsyslog(TS continuity error (%d), ccCounter);
I will try with the recording if the problem reappears and then activate
that line.
The cRepacker messages might be a result of lost TS packets, which
should be reported by the above line.
Another issue might be, that the audio frames do not contain any length
information. Please modify the line
*FrameSize = 0;
in cAudioRepacker::IsValidAudioHeader to
{ *FrameSize = 0; dsyslog(cAudioRepacker: FrameSize == 0); }
for getting this situation reported.
Should I do both these changes at the same time or separately?
\\Kartsa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr diseqc equivalence of szap diseqc n ?
Hello, here VDR's log with your patch : nice -n -19 ./vdr -u root -c /etc/vdr -l 3 -w 90 -s /usr/local/bin/vdrshutdown -P'xine -r -q' t: 1170367257.885, c: 0, r: 0, a: -- t: 1170367257.885, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170367257.921, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367257.921, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_18) t: 1170367257.941, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367258.129, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367258.297, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367258.449, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170367258.485, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_ON) t: 1170367258.485, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170367258.507, c: 0, r: 0, a: == Then I start xine, no change at all. I zap : t: 1170367407.322, c: 0, r: 0, a: -- t: 1170367407.322, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170367407.357, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367407.358, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) t: 1170367407.377, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367407.565, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367407.733, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367407.885, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170367407.921, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367407.922, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170367407.944, c: 0, r: 0, a: == I start to record Musique classique (FTA radio, 13.0E) : t: 1170367493.771, c: 1, r: 0, a: -- t: 1170367493.771, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170367493.889, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367493.891, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) t: 1170367493.909, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367494.165, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367494.401, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367494.637, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170367494.757, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367494.759, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170367494.811, c: 1, r: 0, a: == I zap to Euronews (19.2E): t: 1170367530.794, c: 0, r: 0, a: -- t: 1170367530.794, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A) t: 1170367530.830, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367530.830, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) t: 1170367530.850, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367531.038, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367531.206, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367531.358, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A) t: 1170367531.394, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_ON) t: 1170367531.394, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170367531.416, c: 0, r: 0, a: == ??? I didn't remenber being able to do so with a vanilla vdr ??? I tune to FTA channel on 28.2E : t: 1170367594.434, c: 0, r: 0, a: -- t: 1170367594.434, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A) t: 1170367594.470, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367594.471, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) t: 1170367594.490, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367594.678, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367594.846, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170367594.998, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A) t: 1170367595.034, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170367595.034, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170367595.057, c: 0, r: 0, a: == I start to record it
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x
In [EMAIL PROTECTED], Patrick Mackin wrote: Also generic video cards are increasingly coming with video decoding features, and HDTVs can be connected straight to a PC without the need for a horrible scaler or special screen mode. Although not all the decoding features are available to Linux, dedicated decoder/TV-out cards are looking quite obsolete, and DVB card manufacturers are bound to respond to that. Not to get too off-topic, but I disagree. In north america, from surveying posts on several bulletin boards, vdr usage seems to be 90%+ with FF cards (typically the Nexus-S). Is that HD-capable? HDTV seems quite common in NA, but currently in the UK there are very few HD channels, only available through overpriced subscriptions. It looks unlikely that there'll be any FTA/FTV HD until at least after the analogue terrestrial switch-off in 2012. There's actually the perception with many in NA that vdr doesn't work with budget cards! And while more PCs are adding the built-in functions a FF card provides (Digital audio out, Coax or S-video out, adequate processing power for decoding) everything seems to be moving to mpeg-4. If the Nexus-S requires replacement for HD/MPEG4 I wouldn't be surprised if its successor doesn't feature a decoder. The latest graphics cards support MPEG4 too, including H.264. Someone posted about a new DVB card which does have an MPEG4 decoder recently, but pointed out that it's only a reference design, not a production model. And it's PCI-E, so it doesn't look like the manufacturers are very keen to support old PCs. I know from working regularly with Xvid / mpeg4 files that they require a lot more processing power, and many pcs are older machines dedicated to running vdr, not top of the line full fledged 4 ghz systems. I haven't noticed a big difference, although I've only encountered MPEG4 part 2 (DivX etc), usually at lower resolutions than DVB/DVD, as opposed to HD H.264. I've never regretted owning my FF card, and would look for a FF mpeg4 card if I was in the market. Plus, they always seem the simplest to configure and use with most software, not to mention not requiring a computer monitor to run vdr on FF :) Well that was one of my points too. Connecting a typical HDTV to a PC is pretty much the same as connecting a monitor, not like all the headaches involved in getting a decent PAL or NTSC signal from a standard graphics card. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr diseqc equivalence of szap diseqc n ?
Hello, just after a dvb modules reload : nice -n -19 ./vdr -u root -c /etc/vdr -l 3 -w 90 -s /usr/local/bin/vdrshutdown -P'xine -r -q' t: 1170368152.594, c: 0, r: 0, a: -- t: 1170368152.598, c: 1, r: 0, a: -- t: 1170368152.594, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368152.628, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368152.629, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_18) t: 1170368152.598, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368152.648, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368152.716, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368152.718, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) t: 1170368152.736, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368152.836, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368153.004, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368152.992, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368153.156, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368153.192, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_ON) t: 1170368153.193, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170368153.215, c: 0, r: 0, a: == t: 1170368153.228, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368153.464, c: 1, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368153.584, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368153.586, c: 1, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170368153.638, c: 1, r: 0, a: == t: 1170368156.614, c: 2, r: 0, a: -- t: 1170368156.614, c: 2, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A) t: 1170368156.732, c: 2, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368156.734, c: 2, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) t: 1170368156.752, c: 2, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368157.008, c: 2, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368157.244, c: 2, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368157.480, c: 2, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A) t: 1170368157.600, c: 2, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368157.602, c: 2, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170368157.710, c: 2, r: 0, a: == Start xine, tune to Musique classique : Nothing in the log : I record it... I remove the timer, reload the modules and : nice -n -19 ./vdr -u root -c /etc/vdr -l 3 -w 90 -s /usr/local/bin/vdrshutdown -P'xine -r -q' t: 1170368358.155, c: 0, r: 0, a: -- t: 1170368358.155, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368358.205, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368358.206, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13) t: 1170368358.225, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368358.413, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368358.581, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368358.733, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368358.769, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368358.770, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170368358.792, c: 0, r: 0, a: == I tune to Euronews and start to reccord it : t: 1170368387.590, c: 0, r: 0, a: -- t: 1170368387.590, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368387.626, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF) t: 1170368387.626, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_18) t: 1170368387.646, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368387.834, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368388.002, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, cmd) t: 1170368388.154, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B) t: 1170368388.190, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_ON) t: 1170368388.190, c: 0, r: 0, a: ioctl(fd_frontend, FE_SET_FRONTEND, Frontend) t: 1170368388.212, c: 0, r: 0, a:
Re: [vdr] vdr diseqc equivalence of szap diseqc n ?
Hi, Reinhard Nissl wrote: I'll now add the same output to szap. See attachment. While comparing the output of VDR and szap I've discovered a bug in szap. It didn't set FE_DISEQC_SEND_BURST correctly. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] szap.tar.gz Description: GNU Zip compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] to record or not
hello all wondering if there is a way from the timers menu to only select to record or not record a program. what im wanting to do is set a timer to watch a program but not have vdr record it... not sure but just thinking it would be nice to have a option in the menu to not record but still go to the program... thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] to record or not
I too would like this feature, but if you are using yaepg as many are, it seems like that is a feature the plugin should provide, not vdr. wondering if there is a way from the timers menu to only select to record or not record a program. what im wanting to do is set a timer to watch a program but not have vdr record it... not sure but just thinking it would be nice to have a option in the menu to not record but still go to the program... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
AW: [vdr] to record or not
You should have a look at the BigPatch. It has some switch timer included. Martin -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von abbe normal Gesendet: Donnerstag, 1. Februar 2007 23:42 An: vdr@linuxtv.org Betreff: [vdr] to record or not hello all wondering if there is a way from the timers menu to only select to record or not record a program. what im wanting to do is set a timer to watch a program but not have vdr record it... not sure but just thinking it would be nice to have a option in the menu to not record but still go to the program... thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr BWR1LB~0.PNG Description: PNG image ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] to record or not
On 2/1/07, abbe normal [EMAIL PROTECTED] wrote: hello all wondering if there is a way from the timers menu to only select to record or not record a program. what im wanting to do is set a timer to watch a program but not have vdr record it... not sure but just thinking it would be nice to have a option in the menu to not record but still go to the program... thanks I suggested this feature to Klaus a long time ago and his reply was that it's on the TODO list, but unfortunately at the bottom. I wouldn't think it's a hard thing to do, just add a Record? (y/n) flag to the timer data. If the record flag is set, it records, if not it only changes the channel. At any rate, it is something that Klaus has considered. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
