Hi
I've just installed vdr-1.7.15 on my development box which has a single TT-2300 DVB card and CAM installed. I'm using vdr-xine as my front end.
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
logs look like this:
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available! Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started (pid=2499, tid=2535) Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started (pid=2499, tid=2536) Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended (pid=2499, tid=2536) Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended (pid=2499, tid=2535) Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available!
The same setup works fine under vdr-1.6.0.
Any ideas?
Incidentally, I tried the attached patch for vdr-xine and the VPID issue, but it had no effect.
Also tried recording a channel via skincurses without xine-ui attached, but still get the above errors and corresponding console messages: SetPlayMode: 1 SetPlayMode: 0
Is there more debugging I can turn on? Why am I getting the "receiver on device 1 thread ended" ?
Thanks Simon
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
On Fri, 30 Jul 2010 09:17:23 +0200 Theunis Potgieter theunis.potgieter@gmail.com wrote:
I think the point is the OP wants it to be built in to VDR instead of a plugin. Personally I don't have a problem with having to use a plugin for display, provided it's well supported and closely tracks core VDR development. But I use the Debian packages (based on VDR 1.6 and xine 1.1) so I don't know how much hassle this causes when trying to use the bleeding edge. It would be nice to have BBC HD and ITV HD if I could be bothered to put in the effort. There are some unofficial VDR 1.7 debian packages, but there seem to be about 3 sets, so what to choose? Something more official in Debian's "experimental" section would be nice.
I would get far more involved with VDR, particularly the Debian side of things, but I decided some time ago it would never be quite the program I want (nor are mythtv, freevo or gnome-dvb-daemon) and I'd rather write my own rival, so I wouldn't be able to commit long term to maintaining VDR plugins and packages.
On 30 July 2010 15:40, Tony Houghton h@realh.co.uk wrote:
Correct me if I'm wrong, but that would be backwards to VDR's roadmap. VDR has now also moved the hardware output devices to be a plugin.
-- TH * http://www.realh.co.uk
I would like to dump xine though it is getting stable, it's still a lot of extra crap that needs installing to use it that just waste disk space. Softdevice doesn't support vdpau though does it? I'm still confused about the layers. Seems like X is the layer between vdr and vdpau driver, but we seem to need xine to talk to X and we need vdr-xine plugin to talk to xine. too many layers. We need a plugin that talks directly to X if not the video driver itself. Vdr could talk directly to the driver for video out of the Nexus-s. Why not the main video card?
On 7/30/2010 6:40 AM, Tony Houghton wrote:
On Thu, Jul 29, 2010 at 12:55 PM, Morfsta morfsta@gmail.com wrote:
The only problem is that I doubt it will ever happen. Although I did hear talk about making the vdpau elements from xine-lib into an own library, which I guess would be a step closer. I use xine-lib-1.2 + xine-ui + vdr-xine. However, I never actually use xine-ui and so on since my box is a dedicated htpc. I will never run VDR in a window or want to have any desktop type environment there. Surely there's a lot I have to install that I'll never use but I don't ever see a time when VDR will be able to bypass all that for users such as myself (with dedicated VDR into tv).
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linuxtv@nzbaxters.com wrote:
Not enough information. Assuming channel 1 is a real channel for you, check your xine log and cam log also. Usually "Channel not available" seems to mean the cam can't decrypt the channel or the tuner is in use already (such as a timer is active on another channel).
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linuxtv@nzbaxters.com wrote:
This is a test box with no timers or other front ends, so the tuner isn't in use anywhere. Above result happens no matter which channel I change to - 3 seconds of live TV then thread ends.
I've also tested using a FF card (so no xine front end) and still only getting 3 seconds of video.
Using vdr-xine, XINE logs, all I'm getting is: vdr: osdflush: n: 3, 32.6, timeout: 0, result: 0 vdr: osdflush: n: 2, 20.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 3, 33.6, timeout: 0, result: 0 vdr: osdflush: n: 3, 30.3, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0
CAM logs as follows: SetPlayMode: 1 Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 24 57 00 02 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 07 01 91 04 00 40 00 41 80 02 01 00 . . . . . . . . @ . A . . . . Slot 2: open session 00400041 Slot 2: new MMI (session id 5) 2: --> 01 01 A0 0A 01 92 07 00 00 40 00 41 00 05 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 0B 01 90 02 00 05 9F 88 01 02 01 01 80 02 01 00 . . . . . . . . . . . . . . . . . . . . . Slot 2: <== Display Control (5) Slot 2: ==> Display Reply (5) 2: --> 01 01 A0 0B 01 90 02 00 05 9F 88 02 02 01 01 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 61 01 90 02 00 05 9F 88 0C 58 02 9F 88 03 0B 97 41 6C 70 68 61 43 72 79 70 74 9F 88 03 01 20 9F 88 03 08 50 72 65 73 73 20 4F 4B 9F 88 03 14 59 6F 75 20 61 72 65 20 6E 6F 74 20 65 6E 74 69 74 6C 65 64 9F 88 03 1B 74 6F 20 72 65 63 65 69 76 65 20 74 68 69 73 20 70 72 6F 67 72 61 6D 6D 65 20 21 80 02 01 00 . . . . . a . . . . . . . . X . . . . . . A l p h a C r y p t . . . . . . . . P r e s s O K . . . . Y o u a r e n o t e n t i t l e d . . . . t o r e c e i v e t h i s p r o g r a m m e ! . . . . Slot 2: <== Menu Last (5) Slot 2: <== Text Last (5) 'AlphaCrypt' Slot 2: <== Text Last (5) '' Slot 2: <== Text Last (5) 'Press OK' Slot 2: <== Text Last (5) 'You are not entitled' Slot 2: <== Text Last (5) 'to receive this programme !' SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 01 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EE 01 00 07 01 09 04 06 06 E4 51 frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00) Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 25 03 00 02 Slot 2: ==> Close MMI (5) 2: --> 01 01 A0 09 01 90 02 00 05 9F 88 00 00 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 05 01 95 02 00 05 80 02 01 00 . . . . . . . . . . . . . Slot 2: close session 5 2: --> 01 01 A0 06 01 96 03 00 00 05
If I run vdr-1.6.0 it works fine, it's just vdr-1.7.15 that doesn't. So I'm not thinking this is a system problem.
have made a bit of a breakthrough - I've found any vdr version up to and including vdr-1.7.11 works fine. From vdr-1.7.12 I get the 3 seconds of live TV problem.
Tested vdr-1.7.0,1,2,3,4,5,6,7,8,9,10,11,12,14,15.
This is in the HISTORY for vdr-1.7.12: - The PCR pid in generated PMTs is now set to the channel's PCR pid again. - Fixed determining the frame duration on channels where the PTS deltas jitter by +/-1 around 3600. - The PCR pid is now recorded for channels where this is different from the video PID. To facilitate this, the interfaces of cTransfer, cTransferControl, cRecorder and cReceiver have been modified, so that the PIDs are no longer given in separate parameters, but rather the whole channel is handed down for processing. The old constructor of cReceiver is still available, but it is recommended to plugin authors that they switch to the new interface as soon as possible. When replaying such a recording, the PCR packets are sent to PlayTsVideo()
Could it be something to do with this?
Summary of problem: - vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before "SetPlayMode: 0", blank screen, sequence of "channel not available", then a few seconds of TV (repeats) - system has TT-1501 abd TT-2300 cards - usage of vdr-xine-0.9.3 or not makes no difference. i.e. TT-2300 FF card has same problem with no vdr-xine loaded. - any vdr version 1.7.11 or older does not show this fault.
any ideas?
Hi, Have you updated the firmware of the tt 2300? Check the mailinglist archives for instructions. You need also the newest drivers. BR. Halim
Hi, Ok, I use xineliboutput and vdr-xione here with no errors under vdr-1.7.15. If you have then check you xine-lib installation and the used videodriver. Sorry no other idea. Br. halim
I'm pretty sure it's not xine-lib related.
I also have a FF card (TT-2300) which I run with no plugins - and get the same problem.
Summary of problem: - vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before "SetPlayMode: 0", blank screen, sequence of "channel not available", then a few seconds of TV (repeats) - system has TT-1501 abd TT-2300 cards - usage of vdr-xine-0.9.3 or not makes no difference. i.e. TT-2300 FF card has same problem with no vdr-xine loaded.
- vdr-1.7.11 or older does not show this fault. i.e. vdr-1.7.9 and vdr-1.7.10 work 100% perfect.
I'm still no futher with this, can anyone please help?
I turned on ci.c debugging to see what happens differently between vdr-1.7.11 and vdr-1.7.15.
1.7.11 -> switch to channel 1 and on the console I see: SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EB 01 00 07 01 09 04 06 06 E4 52 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1
in messages, I see: Aug 28 12:53:15 freddy vdr: [17052] switching to channel 1 Aug 28 12:53:15 freddy vdr: [17104] TS buffer on device 1 thread ended (pid=17052, tid=17104) Aug 28 12:53:15 freddy vdr: [17103] buffer stats: 80840 (3%) used Aug 28 12:53:15 freddy vdr: [17103] receiver on device 1 thread ended (pid=17052, tid=17103) Aug 28 12:53:15 freddy vdr: [17105] receiver on device 1 thread started (pid=17052, tid=17105) Aug 28 12:53:15 freddy vdr: [17106] TS buffer on device 1 thread started (pid=17052, tid=17106) Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: operating in MPEG1/2 mode
i.e. ALL OK
In vdr-1.7.15 on the same box, I see: SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start [vAVM]buffered 7.1 frames (v:12.2, a:7.1) SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start [vAVM]buffered 7.3 frames (v:13.0, a:7.3) SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v]
and in messages: Aug 28 12:50:10 freddy vdr: [16633] receiver on device 2 thread started (pid=16557, tid=16633) Aug 28 12:50:10 freddy vdr: [16634] TS buffer on device 2 thread started (pid=16557, tid=16634) Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:14 freddy vdr: [16634] TS buffer on device 2 thread ended (pid=16557, tid=16634) Aug 28 12:50:14 freddy vdr: [16633] buffer stats: 192700 (9%) used Aug 28 12:50:14 freddy vdr: [16633] receiver on device 2 thread ended (pid=16557, tid=16633) Aug 28 12:50:21 freddy vdr: [16557] switching to channel 1 Aug 28 12:50:21 freddy vdr: [16635] receiver on device 1 thread started (pid=16557, tid=16635) Aug 28 12:50:21 freddy vdr: [16636] TS buffer on device 1 thread started (pid=16557, tid=16636) Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:25 freddy vdr: [16636] TS buffer on device 1 thread ended (pid=16557, tid=16636) Aug 28 12:50:25 freddy vdr: [16635] buffer stats: 173712 (8%) used Aug 28 12:50:25 freddy vdr: [16635] receiver on device 1 thread ended (pid=16557, tid=16635)
i.e. I get 3 second "bursts" of live TV, but blank screen as the receiver threads restart
Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason??
On 28.08.2010 03:07, Simon Baxter wrote:
You may want to find out where this message comes from (it certainly doesn't come from the core VDR).
When a receiver is detached from a device, the play mode is set to pmNone (which is 0).
My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream?
Klaus
Hi,
Am 29.08.2010 15:06, schrieb Klaus Schmidinger:
This is just an implementation detail of vdr-xine.
I doubt that vdr-xine does anything which would cause transfer mode to be stopped and restarted.
Bye.
I have the same problem (transfer mode stopping) with plain VDR (no plugins) and a FF card. i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12)
Happy to do any captures etc - any suggestions??
Am 30.08.10 02:05, schrieb Simon Baxter:
have you upgraded the firmware for your FF card, too?
Bye, Matthias
On 30.08.2010 02:05, Simon Baxter wrote:
The only place where a 3 second timeout plays a role that also might cause a channel to become unavailable is in cDevice::Action(), under
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here. This could be caused by recording the PCR packets since version 1.7.12. To debug this, just disable this check, and/or put in some debug printouts.
Klaus
How do I do this? Is it as simple as : - startScrambleDetection = 0; + startScrambleDetection = 1;
or comment out: // if (startScrambleDetection) { // cCamSlot *cs = CamSlot(); // CamSlotNumber = cs ? cs->SlotNumber() : 0; // if (CamSlotNumber) { // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; // int t = time(NULL) - startScrambleDetection; // if (Scrambled) { // if (t > TS_SCRAMBLING_TIMEOUT) // DetachReceivers = true; // } // else if (t > TS_SCRAMBLING_TIME_OK) { // DescramblingOk = true; // startScrambleDetection = 0; // } // } // }
or something else?
I've added some markers in device.c as per: // Check whether the TS packets are scrambled: bool DetachReceivers = false; bool DescramblingOk = false; int CamSlotNumber = 0; if (startScrambleDetection) { cCamSlot *cs = CamSlot(); CamSlotNumber = cs ? cs->SlotNumber() : 0; if (CamSlotNumber) { bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; int t = time(NULL) - startScrambleDetection; if (Scrambled) { printf("scramble detect ONE"); if (t > TS_SCRAMBLING_TIMEOUT) DetachReceivers = true; } else if (t > TS_SCRAMBLING_TIME_OK) { printf("scramble detect TWO"); DescramblingOk = true; startScrambleDetection = 0; } } }
Am getting lots of "scramble detect ONE" messages as per above.......
Now what?
Thanks Klaus
I've commented out the below section in device.c, and I now get continuous video, but some video skips and lots of: Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 mode Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: switching to MPEG1/2 mode Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 mode
Here's what I changed in device.c
void cDevice::Action(void) { if (Running() && OpenDvr()) { while (Running()) { // Read data from the DVR device: uchar *b = NULL; if (GetTSPacket(b)) { if (b) { int Pid = TsPid(b); // Check whether the TS packets are scrambled: bool DetachReceivers = false; bool DescramblingOk = false; int CamSlotNumber = 0; if (startScrambleDetection) { cCamSlot *cs = CamSlot(); CamSlotNumber = cs ? cs->SlotNumber() : 0; // if (CamSlotNumber) { // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; // int t = time(NULL) - startScrambleDetection; // if (Scrambled) { // if (t > TS_SCRAMBLING_TIMEOUT) // DetachReceivers = true; // } // else if (t > TS_SCRAMBLING_TIME_OK) { // DescramblingOk = true; // startScrambleDetection = 0; // } // } } // Distribute the packet to all attached receivers: Lock();
Any ideas?
This cVideoRepacker problem has also been fixed with the attached patch.
So I've managed to get vdr-1.7.15 working just fine now, by disabling this scramble check in device.c. Bit of a dirty hack!!!
On 09/03/10 22:12, Simon Baxter wrote:
Looks like there are TS packets in your stream that are marked as "scrambled", but not unscrambled by the CAM.
Do you have any CAM in your system at all?
Are the channels where this happens scrambled?
Do these channels have separate VPID and PPID?
Does the problem go away if, instead of the above change, you comment out the line
(Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&
in cReceiver::AddPids()?
Klaus
-
Halim Sahin -
Klaus Schmidinger -
Matthias Fechner -
Morfsta -
Reinhard Nissl -
Simon Baxter -
Theunis Potgieter -
Timothy D. Lenz -
Tony Houghton -
VDR User