Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
Added in device.c debug output to cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) : GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 2 0 1 -1 no usable CAM slots! GetDevice 2 0 1 -1 no usable CAM slots! GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 2 0 1 -1 no usable CAM slots! GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 1 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 1 0 1 -1 no usable CAM slots! GetDevice 1 0 1 -1 no usable CAM slots! GetDevice 1 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 2 0 1 -1 j = 1, i = 0, imp = 062C4C5A, Impact = device 0 GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4A, Impact = device 0 GetDevice 3 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 3 0 1 -1 no usable CAM slots! GetDevice 3 0 1 -1 no usable CAM slots! GetDevice 3 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 3 0 1 -1 no usable CAM slots! GetDevice 4 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 4 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 5 0 1 -1 j = 0, i = 0, imp = 062C4C7E, Impact = device 0 GetDevice 5 0 1 -1 j = 0, i = 0, imp = 020C4C6E, Impact = device 0 GetDevice 6 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 6 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 6 0 1 -1 no usable CAM slots! GetDevice 7 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 7 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 7 0 1 -1 no usable CAM slots! GetDevice 8 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 8 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 8 0 1 -1 no usable CAM slots! GetDevice 9 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 9 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 9 0 1 -1 no usable CAM slots! GetDevice 9 0 1 -1 no usable CAM slots! GetDevice 10 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 10 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 10 0 1 -1 no usable CAM slots! GetDevice 10 0 1 -1 no usable CAM slots! and syslog gives : May 4 10:20:40 localhost vdr: [645] TS buffer on device 1 thread started (pid=390, tid=645) May 4 10:20:43 localhost vdr: [643] transfer thread ended (pid=390, tid=643) May 4 10:20:43 localhost vdr: [645] TS buffer on device 1 thread ended (pid=390, tid=645) May 4 10:20:43 localhost vdr: [644] buffer stats: 92308 (4%) used May 4 10:20:43 localhost vdr: [644] receiver on device 1 thread ended (pid=390, tid=644) May 4 10:20:50 localhost vdr: [390] switching to channel 3 May 4 10:20:50 localhost vdr: [390] buffer stats: 66364 (3%) used May 4 10:20:50 localhost vdr: [390] info: Channel not available! May 4 10:20:58 localhost vdr: [390] switching to channel 4 May 4 10:20:58 localhost vdr: [655] transfer thread started (pid=390, tid=655) May 4 10:20:58 localhost vdr: [656] receiver on device 1 thread started (pid=390, tid=656) May 4 10:20:58 localhost vdr: [657] TS buffer on device 1 thread started (pid=390, tid=657) May 4 10:20:58 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:20:58 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 10:21:01 localhost vdr: [655] transfer thread ended (pid=390, tid=655) May 4 10:21:01 localhost vdr: [390] CAM 2: unassigned May 4 10:21:01 localhost vdr: [390] switching to channel 5 May 4 10:21:01 localhost vdr: [390] buffer stats: 64484 (3%) used May 4 10:21:02 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:21:02 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 10:21:02 localhost vdr: [657] TS buffer on device 1 thread ended (pid=390, tid=657) May 4 10:21:02 localhost vdr: [656] buffer stats: 64108 (3%) used May 4 10:21:02 localhost vdr: [656] receiver on device 1 thread ended (pid=390, tid=656) May 4 10:21:04 localhost vdr: [390] CAM 2: assigned to device 1 May 4 10:21:04 localhost vdr: [390] switching to channel 6 May 4 10:21:04 localhost vdr: [667] transfer thread started (pid=390, tid=667) May 4 10:21:04 localhost vdr: [668] receiver on device 1 thread started (pid=390, tid=668) May 4 10:21:04 localhost vdr: [669] TS buffer on device 1 thread started (pid=390, tid=669) May 4 10:21:04 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:21:04 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 10:21:08 localhost vdr: [667] transfer thread ended (pid=390, tid=667) May 4 10:21:08 localhost vdr: [669] TS buffer on device 1 thread ended (pid=390, tid=669) May 4 10:21:08 localhost vdr: [668]
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
I also increased values in #define TS_SCRAMBLING_CONTROL 0xC0 #define TS_SCRAMBLING_TIMEOUT 5 // seconds to wait until a TS becomes unscrambled #define TS_SCRAMBLING_TIME_OK15 // seconds before a Channel/CAM combination is marked as known to decrypt still the same. May 4 10:33:34 localhost vdr: [1348] info: Channel not available! May 4 10:33:45 localhost vdr: [1348] switching to channel 21 May 4 10:33:45 localhost vdr: [1535] transfer thread started (pid=1348, tid=1535) May 4 10:33:45 localhost vdr: [1536] receiver on device 1 thread started (pid=1348, tid=1536) May 4 10:33:46 localhost vdr: [1537] TS buffer on device 1 thread started (pid=1348, tid=1537) May 4 10:33:48 localhost vdr: [1352] ERROR: CAM 2: session for resource identifier 00400041 already exists (1/1) May 4 10:33:51 localhost vdr: [1535] transfer thread ended (pid=1348, tid=1535) May 4 10:33:51 localhost vdr: [1537] TS buffer on device 1 thread ended (pid=1348, tid=1537) May 4 10:33:51 localhost vdr: [1536] buffer stats: 126148 (6%) used May 4 10:33:51 localhost vdr: [1536] receiver on device 1 thread ended (pid=1348, tid=1536) May 4 10:33:56 localhost vdr: [1348] switching to channel 21 May 4 10:33:56 localhost vdr: [1348] buffer stats: 45120 (2%) used May 4 10:33:56 localhost vdr: [1348] info: Channel not available! May 4 10:34:07 localhost vdr: [1348] switching to channel 21 May 4 10:34:07 localhost vdr: [1556] transfer thread started (pid=1348, tid=1556) May 4 10:34:07 localhost vdr: [1557] receiver on device 1 thread started (pid=1348, tid=1557) May 4 10:34:07 localhost vdr: [1558] TS buffer on device 1 thread started (pid=1348, tid=1558) May 4 10:34:09 localhost vdr: [1352] ERROR: CAM 2: session for resource identifier 00400041 already exists (1/1) May 4 10:34:13 localhost vdr: [1556] transfer thread ended (pid=1348, tid=1556) May 4 10:34:13 localhost vdr: [1558] TS buffer on device 1 thread ended (pid=1348, tid=1558) May 4 10:34:13 localhost vdr: [1557] buffer stats: 121260 (5%) used May 4 10:34:13 localhost vdr: [1557] receiver on device 1 thread ended (pid=1348, tid=1557) May 4 10:34:18 localhost vdr: [1348] switching to channel 21 May 4 10:34:18 localhost vdr: [1348] buffer stats: 44744 (2%) used May 4 10:34:18 localhost vdr: [1348] info: Channel not available! May 4 10:34:18 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:34:18 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 Pierre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 10:34, Pierre-Yves Paranthoen (PERSO) wrote: I also increased values in #define TS_SCRAMBLING_CONTROL 0xC0 #define TS_SCRAMBLING_TIMEOUT 5 // seconds to wait until a TS becomes unscrambled #define TS_SCRAMBLING_TIME_OK15 // seconds before a Channel/CAM combination is marked as known to decrypt still the same. May 4 10:33:34 localhost vdr: [1348] info: Channel not available! May 4 10:33:45 localhost vdr: [1348] switching to channel 21 May 4 10:33:45 localhost vdr: [1535] transfer thread started (pid=1348, tid=1535) May 4 10:33:45 localhost vdr: [1536] receiver on device 1 thread started (pid=1348, tid=1536) May 4 10:33:46 localhost vdr: [1537] TS buffer on device 1 thread started (pid=1348, tid=1537) May 4 10:33:48 localhost vdr: [1352] ERROR: CAM 2: session for resource identifier 00400041 already exists (1/1) This is getting stranger by the minute... Why would the CAM try to establish another MMI resource? Are you sure this is an unpatched version of VDR 1.7.0 (except for the patch to device.c I gave you)? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] e-tobi ubuntu hardy
Hi, I had a similar situation with xine plugin and finally I decided to use only e-tobi repositories (more plugins than in ubuntu builds) and softdevice plugin instead of xinelib plugin compiled from source in the following way: apt-get source vdr-plugin-softdevice apt-get build-dep vdr-plugin-softdevice cd directory with plugin source fakeroot debian/rules binary It build vdr-plugin-softdevice-***.deb and it can be successfully use with vdr. But remember, use ONLY e-tobi repositories. You can check version in synaptic. In the same way you can build any vdr plugin from e-tobi repositories: ## VDR sources deb http://e-tobi.net/vdr-experimental/ etch base addons vdr-standard deb-src http://e-tobi.net/vdr-experimental/ etch base addons vdr-standard Good luck, Yarema Leo Márquez написав(ла): Hi, I'm trying to set vdr building the packages from the e-tobi source packages. I'm doing this because I want to run vdr as streamdev client, with no dvb card in the client system. The e-tobi source I'm using is: deb-src http://e-tobi.net/vdr-experimental etch base addons vdr-multipatch The problem I have is that if I do: sudo apt-get build-dep vdr-plugin-xineliboutput The system says me that any version of the libxine-dev package can satisfy the xineliboutput dependencies. If I ignore the message and try to build the .deb packages (satisfying manually the dependences) there is a moment that apt ask me to update the vdr package. At this point I am a bit confused because I understand that this is a conflict between my e-tobi installed vdr and the ubuntu hardy vdr package. My goal on this is get a streamdev client vdr box with xineliboutput output. Could anyone advise me to acquire my objective? Thank you. Leo ___ 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] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 10:23, Pierre-Yves Paranthoen (PERSO) wrote:
Added in device.c debug output to cDevice::GetDevice(const cChannel
*Channel, int Priority, bool LiveView) :
GetDevice 2 0 1 -1
j = 1, i = 0, imp = 020C4C4B, Impact =
device 0
GetDevice 2 0 1 -1
no usable CAM slots!
...
Looks like for some reason the CAM is not usable at this time.
Please apply the attched patch instead of the previous one.
It produces additional output and writes it into the syslog,
so that it will be in sync with the other log messages.
Klaus
--- device.c 2008/04/12 14:12:14 2.2
+++ device.c 2008/05/04 09:24:16
@@ -372,26 +372,35 @@
cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView)
{
+ dsyslog(GetDevice %d %d %d %d %04X, Channel-Number(), Priority, LiveView, avoidDevice ? avoidDevice-CardIndex() : -1, Channel-Ca());//XXX
cDevice *AvoidDevice = avoidDevice;
avoidDevice = NULL;
// Collect the current priorities of all CAM slots that can decrypt the channel:
int NumCamSlots = CamSlots.Count();
+ dsyslog(NumCamSlots = %d, NumCamSlots);//XXX
int SlotPriority[NumCamSlots];
int NumUsableSlots = 0;
if (Channel-Ca() = CA_ENCRYPTED_MIN) {
for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
SlotPriority[CamSlot-Index()] = MAXPRIORITY + 1; // assumes it can't be used
if (CamSlot-ModuleStatus() == msReady) {
+dsyslog(CAM %d ready, CamSlot-Index());//XXX
if (CamSlot-ProvidesCa(Channel-Caids())) {
+ dsyslog(CAM %d provides CA, CamSlot-Index());//XXX
if (!ChannelCamRelations.CamChecked(Channel-GetChannelID(), CamSlot-SlotNumber())) {
SlotPriority[CamSlot-Index()] = CamSlot-Priority();
NumUsableSlots++;
+ dsyslog(NumUsableSlots = %d, NumUsableSlots);//XXX
}
+ else dsyslog(ChannelCamRelations.CamChecked(%s, %d) = 0, *Channel-GetChannelID().ToString(), CamSlot-SlotNumber());//XXX
}
}
+ else dsyslog(CAM %d not ready, CamSlot-Index());//XXX
}
if (!NumUsableSlots)
+{dsyslog(no usable CAM slots!);//XXX
return NULL; // no CAM is able to decrypt this channel
+}//XXX
}
bool NeedsDetachReceivers = false;
@@ -432,6 +441,7 @@
imp = 1; imp |= NumUsableSlots ? 0 : device[i]-HasCi(); // avoid cards with Common Interface for FTA channels
imp = 1; imp |= device[i]-HasDecoder(); // avoid full featured cards
imp = 1; imp |= NumUsableSlots ? !ChannelCamRelations.CamDecrypt(Channel-GetChannelID(), j + 1) : 0; // prefer CAMs that are known to decrypt this channel
+ dsyslog(j = %d, i = %d, imp = %08X, Impact = %08X, j, i, imp, Impact);//XXX
if (imp Impact) {
// This device has less impact than any previous one, so we take it.
Impact = imp;
@@ -446,6 +456,7 @@
break; // no CAM necessary, so just one loop over the devices
}
if (d) {
+ dsyslog(device %d, d-CardIndex());//XXX
if (NeedsDetachReceivers)
d-DetachAllReceivers();
if (s) {
@@ -460,6 +471,7 @@
else if (d-CamSlot() !d-CamSlot()-IsDecrypting())
d-CamSlot()-Assign(NULL);
}
+ else dsyslog(no device found);//XXX
return d;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Judder with interlaced channels
could you show the syslog/xine/ffmeg outputs during this problem. It seems to is ffmpeg problem Igor -Original Message- From: [EMAIL PROTECTED] To: vdr@linuxtv.org Date: Fri, 2 May 2008 17:40:44 +0200 Subject: [vdr] Judder with interlaced channels I have some problems with interlaced channels on SD HDTV. Judder and jitter and its good visible when I using a SD channel with a ticker-tape. If I tune to Discovery HD 1080i its shaking and stutter around but 720P channel like National Geographic HD are smooth. I don't know where to look at. My configurations : 1.) DualCore AMD , 2GB memory, Suse 10.3, vdr 1.6.0, regular dvb drivers from suse dvd and tt budget 1500-ci (cam=aston 1.07) 2.) SingleCore AMD, 1GB memory, Suse 10.3 vdr 1.7.0 multiproto dvb drivers incl, some patches and tt budget 3200-ci (cam=aston 1.07) Booth systems has the same problem and its not related to lnb or signal. I have check it with my humax hdci 2000 and picture is very good and smooth movements. After record some channels and ftp it to a windows system or apple its visible to in for example Media Player or Media Player Classic. With streamdev the same. Suggestions? Please help me out. Jean-Paul ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xine 0.8.0 to 0.8.2...now sound slipping
Hi I was running vdr-1.6.0 with vdr-xine-0.8.0 and upgraded (for no particular reason!) to vdr-xine-0.8.2. I now have occasional audio/video sync issues when replaying recordings, often cured by stopping and restarting the playback.This happens with new and old, previously good, recordings. I also have a lot more video quality issues : audio skips, messages like: Apr 28 09:31:42 callin vdr: [12944] cAudioRepacker(0xC0): skipped 208 bytes to sync on next audio frame Apr 28 09:31:42 callin vdr: [12944] PES packet shortened to 2526 bytes (expected: 2894 bytes) but there has also been some cable upgrades in my area latelyso these might be unrelated? I've tried downgrading back to 0.8.0 (by recompiling sources from Reinhard's website) but get vdr-xine: Client connect failed! messages. So suspect I'd need to do something else if I want to downgrade. Any ideas? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV-feeds (was - OT: ITV HD Testing on Eurobird but receivable with VDR)
Hi thanks for the interesting news. BTW - is there any HDTV-feeds from satellites ? does somebody watch it by vdr ? Igor -Original Message- From: Morfsta [EMAIL PROTECTED] To: VDR Mailing List vdr@linuxtv.org Date: Fri, 2 May 2008 20:58:32 +0100 Subject: [vdr] OT: ITV HD Testing on Eurobird but receivable with VDR Hi, For those of you interested in picking up strange test broadcasts, ITV HD is currently testing on Eurobird 1 @ 28.5E. Apparently the channel is currently broadcasting in H.222 (MPEG4 in an MPEG2 stream?), but can be picked up if you are using VDR+XINE+COREAVC. Most set top box satellite receivers can't pull in this channel at the moment. Presently they are showing a loop of HD images of London at 1920x1088i. I had to manually enter the information: 11428H / 27500 VPID: 3401 DPID: 3402 SPID: 54207 Anyway, if you are into picking up strange new test broadcasts (particularly HD) with your VDR box then enjoy. Cheers, Morfsta ___ 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] Upgrading from 1.4.7 to 1.7.0 : enabling #define
This is getting stranger by the minute... Why would the CAM try to establish another MMI resource? Are you sure this is an unpatched version of VDR 1.7.0 (except for the patch to device.c I gave you)? Klaus It's a native unpatched vdr-1.7.0. I try the patch Pierre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
Here are the results with the device.c patch you gave me : May 4 15:27:15 localhost vdr: [7031] video directory scanner thread started (pid=7030, tid=7031) May 4 15:27:15 localhost vdr: [7030] reading EPG data from /video/epg.data May 4 15:27:15 localhost vdr: [7032] video directory scanner thread started (pid=7030, tid=7032) May 4 15:27:15 localhost vdr: [7032] video directory scanner thread ended (pid=7030, tid=7032) May 4 15:27:15 localhost vdr: [7030] probing /dev/dvb/adapter0/frontend0 May 4 15:27:15 localhost vdr: [7031] video directory scanner thread ended (pid=7030, tid=7031) May 4 15:27:15 localhost vdr: [7034] CI adapter on device 0 thread started (pid=7030, tid=7034) May 4 15:27:15 localhost vdr: [7030] device 1 provides: DVBS May 4 15:27:15 localhost vdr: [7030] found 1 video device May 4 15:27:15 localhost vdr: [7030] initializing plugin: remote (0.3.9): Remote control May 4 15:27:15 localhost vdr: [7030] setting primary device to 1 May 4 15:27:15 localhost vdr: [7035] tuner on device 1 thread started (pid=7030, tid=7035) May 4 15:27:15 localhost vdr: [7036] section handler thread started (pid=7030, tid=7036) May 4 15:27:15 localhost vdr: [7030] assuming manual start of VDR May 4 15:27:15 localhost vdr: [7030] SVDRP listening on port 2001 May 4 15:27:15 localhost vdr: [7030] setting current skin to sttng May 4 15:27:15 localhost vdr: [7030] loading /etc/vdr/themes/sttng-default.theme May 4 15:27:15 localhost vdr: [7030] starting plugin: remote May 4 15:27:15 localhost vdr: [7030] plugin 'remote' called obsolete function RegisterI18n() May 4 15:27:15 localhost vdr: [7030] remote: using '/dev/input/event3' May 4 15:27:15 localhost vdr: [7030] remote-event3: autorepeat supported May 4 15:27:15 localhost vdr: [7030] remote-event3: exclusive access granted May 4 15:27:15 localhost vdr: [7030] remote-event3: keymap loaded '/proc/av7110_ir' flags 001e4000 May 4 15:27:15 localhost vdr: [7030] remote: using 'tcp:' May 4 15:27:15 localhost vdr: [7030] remote control remote-event3 - keys known May 4 15:27:15 localhost vdr: [7030] remote control remote-tcp: - keys known May 4 15:27:15 localhost vdr: [7030] remote control KBD - keys known May 4 15:27:15 localhost vdr: [7039] KBD remote control thread started (pid=7030, tid=7039) May 4 15:27:16 localhost vdr: [7034] CAM 2: module present May 4 15:27:17 localhost vdr: [7034] CAM 1: no module present May 4 15:27:17 localhost vdr: [7034] CAM 2: module ready May 4 15:27:28 localhost vdr: [7038] connect from 192.168.3.245, port 51122 - accepted May 4 15:27:45 localhost vdr: [7030] not all devices ready after 30 seconds May 4 15:27:45 localhost vdr: [7030] switching to channel 2 May 4 15:27:45 localhost vdr: [7030] GetDevice 2 0 1 -1 0500 May 4 15:27:45 localhost vdr: [7030] NumCamSlots = 2 May 4 15:27:45 localhost vdr: [7030] CAM 0 not ready May 4 15:27:45 localhost vdr: [7030] CAM 1 ready May 4 15:27:45 localhost vdr: [7030] no usable CAM slots! May 4 15:27:45 localhost vdr: [7030] info: Channel not available! May 4 15:27:45 localhost vdr: [7030] switching to channel 1 May 4 15:27:45 localhost vdr: [7030] GetDevice 1 0 1 -1 0500 May 4 15:27:45 localhost vdr: [7030] NumCamSlots = 2 May 4 15:27:45 localhost vdr: [7030] CAM 0 not ready May 4 15:27:45 localhost vdr: [7030] CAM 1 ready May 4 15:27:45 localhost vdr: [7030] no usable CAM slots! May 4 15:27:45 localhost vdr: [7030] info: Channel not available! May 4 15:27:45 localhost vdr: [7030] timer 1 (46 2255- 'STARGATE ATLANTIS') set to event Tue 06.05.2008 23:05-23:50 'STARGATE ATLANTIS' May 4 15:27:45 localhost vdr: [7030] timer 2 (46 2340-0050 'STARGATE ATLANTIS') set to event Tue 06.05.2008 23:50-00:35 'STARGATE ATLANTIS' May 4 15:27:45 localhost vdr: [7030] timer 3 (23 1750-2010 'SERENITY') set to event Sun 04.05.2008 18:00-20:00 'SERENITY' May 4 15:27:53 localhost vdr: [7030] GetDevice 2 0 1 -1 0500 May 4 15:27:53 localhost vdr: [7030] NumCamSlots = 2 May 4 15:27:53 localhost vdr: [7030] CAM 0 not ready May 4 15:27:53 localhost vdr: [7030] CAM 1 ready May 4 15:27:53 localhost vdr: [7030] no usable CAM slots! May 4 15:27:53 localhost vdr: [7030] GetDevice 3 0 1 -1 0500 May 4 15:27:53 localhost vdr: [7030] NumCamSlots = 2 May 4 15:27:53 localhost vdr: [7030] CAM 0 not ready May 4 15:27:53 localhost vdr: [7030] CAM 1 ready May 4 15:27:53 localhost vdr: [7030] no usable CAM slots! May 4 15:27:53 localhost vdr: [7030] GetDevice 4 0 1 -1 0500 May 4 15:27:53 localhost vdr: [7030] NumCamSlots = 2 May 4 15:27:53 localhost vdr: [7030] CAM 0 not ready May 4 15:27:53 localhost vdr: [7030] CAM 1 ready May 4 15:27:53 localhost vdr: [7030] no usable CAM slots! May 4 15:27:53 localhost vdr: [7030] GetDevice 5 0 1 -1 May 4 15:27:53 localhost vdr: [7030] NumCamSlots = 2 May 4 15:27:53 localhost vdr: [7030] j = 0, i = 0, imp = 020C4C6E, Impact = May 4 15:27:53 localhost vdr: [7030] device 0 May 4 15:27:53 localhost vdr: [7030]
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 15:31, Pierre-Yves Paranthoen (PERSO) wrote: Here are the results with the device.c patch you gave me : ... May 4 15:28:08 localhost vdr: [7030] edited channel 1 TF1;CSAT:11895:vC34O0S0:S19.2E:27500:171:124=fra,125=eng:53:0:8371:1:1074:0 ... May 4 15:28:29 localhost vdr: [7030] switching to channel 1 May 4 15:28:29 localhost vdr: [7030] GetDevice 1 0 1 -1 May 4 15:28:29 localhost vdr: [7030] NumCamSlots = 2 May 4 15:28:29 localhost vdr: [7030] j = 0, i = 0, imp = 020C4C6E, Impact = May 4 15:28:29 localhost vdr: [7030] device 0 ... May 4 15:28:32 localhost vdr: [7036] changing caids of channel 1 from 0 to 500,100 May 4 15:28:32 localhost vdr: [7030] retuning due to modification of channel 1 May 4 15:28:32 localhost vdr: [7030] switching to channel 1 May 4 15:28:32 localhost vdr: [7030] GetDevice 1 0 1 -1 0500 May 4 15:28:32 localhost vdr: [7030] NumCamSlots = 2 May 4 15:28:32 localhost vdr: [7030] CAM 0 not ready May 4 15:28:32 localhost vdr: [7030] CAM 1 ready May 4 15:28:32 localhost vdr: [7030] no usable CAM slots! May 4 15:28:32 localhost vdr: [7030] info: Channel not available! After changing the CA id of channel 1 to '0', the first device is chosen. Then the CA id is automatically updated to 500,100 and the channel is retuned. CAM 2 (index 1) is ready, but apparently doesn't provide CA id 500 or 100. What I'm missing in your log is the actual application information message of your CAM - something like CAM 2: AlphaCrypt, 01, 4A20, 4A20 Please change the 'dbgprotocol' to 'dsyslog' in the following lines of ci.c: 515: dbgprotocol(Slot %d: == Application Info (%d)\n, Tc()-CamSlot()-SlotNumber(), SessionId()); 721: dbgprotocol(Slot %d: == Ca Pmt Reply (%d), Tc()-CamSlot()-SlotNumber(), SessionId()); 731: dbgprotocol( %d, pnr); 735: dbgprotocol( %02X, *d); 752: dbgprotocol( %02X, caepl); 761: dbgprotocol( %d=%02X, pid, caees); 772: dbgprotocol(\n); and repeat the test. Make sure the Application Info and Ca Pmt Reply messages are in your log excerpt. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
One part of the pb is that my cam module is ramdomly identified under 1.7.0 that might be the reason why the info Application Info and Ca Pmt Reply is not in the log. VDR-1.7.0 most gives CAM 2: module present CAM 2: module ready instead of giving Aston Module 1.0300, 01, 0100,0100 (info taken from vdr-1.4.7). When it's correctly being identified and trying to access CAM informations under OSD, VDR-1.7 responds ERROR: Can't open CAM menu! A CAM reset gives then a basic information : 2 CAM ready and nothing else. Of course no decryption. Here is the log of matching my explainations : May 4 16:07:49 localhost vdr: [8251] CAM 2: module present May 4 16:07:50 localhost vdr: [8251] CAM 1: no module present May 4 16:07:50 localhost vdr: [8251] CAM 2: module ready May 4 16:07:54 localhost vdr: [8251] Slot 2: == Application Info (2) May 4 16:07:54 localhost vdr: [8251] CAM 2: Aston Module 1.0300, 01, 0100, 0100 May 4 16:07:58 localhost vdr: [8251] CAM 2: doesn't reply to QUERY - only a single channel can be decrypted May 4 16:07:58 localhost vdr: [8247] switching to channel 2 May 4 16:07:58 localhost vdr: [8247] GetDevice 2 0 1 -1 0500 May 4 16:07:58 localhost vdr: [8247] NumCamSlots = 2 May 4 16:07:58 localhost vdr: [8247] CAM 0 not ready May 4 16:07:58 localhost vdr: [8247] CAM 1 ready May 4 16:07:58 localhost vdr: [8247] CAM 1 provides CA May 4 16:07:58 localhost vdr: [8247] NumUsableSlots = 1 May 4 16:07:58 localhost vdr: [8247] j = 1, i = 0, imp = 020C4C4B, Impact = May 4 16:07:58 localhost vdr: [8247] device 0 May 4 16:07:58 localhost vdr: [8247] CAM 2: assigned to device 1 May 4 16:07:58 localhost vdr: [8265] transfer thread started (pid=8247, tid=8265) May 4 16:07:58 localhost vdr: [8266] receiver on device 1 thread started (pid=8247, tid=8266) May 4 16:07:58 localhost vdr: [8267] TS buffer on device 1 thread started (pid=8247, tid=8267) May 4 16:07:58 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 16:07:58 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 16:08:34 localhost vdr: [8247] switching to channel 1 May 4 16:08:34 localhost vdr: [8265] transfer thread ended (pid=8247, tid=8265) May 4 16:08:35 localhost vdr: [8247] buffer stats: 5640 (0%) used May 4 16:08:35 localhost vdr: [8247] GetDevice 1 0 1 -1 0500 May 4 16:08:35 localhost vdr: [8247] NumCamSlots = 2 May 4 16:08:35 localhost vdr: [8247] CAM 0 not ready May 4 16:08:35 localhost vdr: [8247] CAM 1 ready May 4 16:08:35 localhost vdr: [8247] CAM 1 provides CA May 4 16:08:35 localhost vdr: [8247] NumUsableSlots = 1 May 4 16:08:35 localhost vdr: [8247] j = 1, i = 0, imp = 020C4C4B, Impact = May 4 16:08:35 localhost vdr: [8247] device 0 May 4 16:08:35 localhost vdr: [8303] transfer thread started (pid=8247, tid=8303) May 4 16:08:35 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 16:08:35 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 16:08:35 localhost vdr: [8267] TS buffer on device 1 thread ended (pid=8247, tid=8267) May 4 16:08:35 localhost vdr: [8266] buffer stats: 25568 (1%) used May 4 16:08:35 localhost vdr: [8266] receiver on device 1 thread ended (pid=8247, tid=8266) May 4 16:08:35 localhost vdr: [8304] receiver on device 1 thread started (pid=8247, tid=8304) May 4 16:08:35 localhost vdr: [8305] TS buffer on device 1 thread started (pid=8247, tid=8305) May 4 16:08:39 localhost vdr: [8303] transfer thread ended (pid=8247, tid=8303) May 4 16:08:39 localhost vdr: [8305] TS buffer on device 1 thread ended (pid=8247, tid=8305) May 4 16:08:39 localhost vdr: [8304] buffer stats: 83096 (3%) used May 4 16:08:39 localhost vdr: [8304] receiver on device 1 thread ended (pid=8247, tid=8304) May 4 16:08:39 localhost vdr: [8247] switching to channel 1 May 4 16:08:39 localhost vdr: [8247] buffer stats: 47564 (2%) used May 4 16:08:39 localhost vdr: [8247] GetDevice 1 0 1 -1 0500 May 4 16:08:39 localhost vdr: [8247] NumCamSlots = 2 May 4 16:08:39 localhost vdr: [8247] CAM 0 not ready May 4 16:08:39 localhost vdr: [8247] CAM 1 ready May 4 16:08:39 localhost vdr: [8247] CAM 1 provides CA May 4 16:08:39 localhost vdr: [8247] ChannelCamRelations.CamChecked(S19.2E-1-1074-8371, 2) = 0 May 4 16:08:39 localhost vdr: [8247] no usable CAM slots! May 4 16:08:39 localhost vdr: [8247] info: Channel not available! May 4 16:08:50 localhost vdr: [8247] switching to channel 1 May 4 16:08:50 localhost vdr: [8247] GetDevice 1 0 1 -1 0500 May 4 16:08:50 localhost vdr: [8247] NumCamSlots = 2 May 4 16:08:50 localhost vdr: [8247] CAM 0 not ready May 4 16:08:50 localhost vdr: [8247] CAM 1 ready May 4 16:08:50 localhost vdr: [8247] CAM 1 provides CA May 4 16:08:50 localhost vdr: [8247] ChannelCamRelations.CamChecked(S19.2E-1-1074-8371, 2) = 0 May 4 16:08:50 localhost vdr: [8247] no usable CAM slots! May 4 16:08:50 localhost vdr: [8247] info: Channel not available! May 4 16:09:00 localhost vdr: [8247] GetDevice 2 0 1 -1 0500
Re: [vdr] Watching old recordings with DVB subtitles with 1.6.0
Petri Helin wrote:
Rolf Ahrenberg wrote:
On Sat, 12 Apr 2008, Ville Skyttä wrote:
After figuring out how to access the subtitles menu (my remote.conf was from
1.4.x series so there was no button binding for it), yes, I do see an entry
named 57 there. Selecting it gives me the Finnish subtitles I was looking
for. Thanks for the tip.
You could also map 57 to fin in info.vdr of all those old recordings
and afterwards VDR automatically selects subtitles according to
preferred languages.
Is 57 dependent on the in subtitling language, or is it constant for
all old recordings?
It is constant. 57 is for the first subtitle track, 58 for the second.
If it is constant, could VDR be patched easily to
select 57 in case preferred subtitles are not found?
Yes. Patch attached.
--
Anssi Hannula
Index: vdr-1.6.0-57/device.c
===
--- vdr-1.6.0-57/device.c
+++ vdr-1.6.0-57/device.c 2008-05-04 18:33:18.0 +0300
@@ -1100,7 +1100,9 @@
int LanguagePreference = INT_MAX; // higher than the maximum possible
value
for (int i = ttSubtitleFirst; i = ttSubtitleLast; i++) {
const tTrackId *TrackId = GetTrack(eTrackType(i));
- if (TrackId TrackId-id
I18nIsPreferredLanguage(Setup.SubtitleLanguages, TrackId-language,
LanguagePreference))
+ // Fall back to languageless ttSubtitleFirst+8 track created by old
subtitles patch if present
+ if (TrackId TrackId-id
(I18nIsPreferredLanguage(Setup.SubtitleLanguages, TrackId-language,
LanguagePreference)
+ || ((i == ttSubtitleFirst + 8) !(*TrackId-language)
LanguagePreference == INT_MAX)))
PreferredTrack = eTrackType(i);
}
// Make sure we're set to an available subtitle track:
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 16:40, Pierre-Yves Paranthoen (PERSO) wrote: One part of the pb is that my cam module is ramdomly identified under 1.7.0 that might be the reason why the info Application Info and Ca Pmt Reply is not in the log. VDR-1.7.0 most gives CAM 2: module present CAM 2: module ready instead of giving Aston Module 1.0300, 01, 0100,0100 (info taken from vdr-1.4.7). When it's correctly being identified and trying to access CAM informations under OSD, VDR-1.7 responds ERROR: Can't open CAM menu! A CAM reset gives then a basic information : 2 CAM ready and nothing else. Of course no decryption. Here is the log of matching my explainations : May 4 16:07:49 localhost vdr: [8251] CAM 2: module present May 4 16:07:50 localhost vdr: [8251] CAM 1: no module present May 4 16:07:50 localhost vdr: [8251] CAM 2: module ready May 4 16:07:54 localhost vdr: [8251] Slot 2: == Application Info (2) May 4 16:07:54 localhost vdr: [8251] CAM 2: Aston Module 1.0300, 01, 0100, 0100 So the application information is being received. I'm afraid I was looking at the wrong lines when telling you which 'dbgprotocol's to change. Please also change the ones in lines 696: dbgprotocol(Slot %d: == Ca Info (%d), Tc()-CamSlot()-SlotNumber(), SessionId()); 702: dbgprotocol( %04X, id); 713: dbgprotocol(\n); Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TS recordings?
On 05/04/08 18:18, Teemu Suikki wrote: Sorry if I'm asking FAQ's, I tried to search the old articles but there was no clear answer.. I have been trying to watch vdr recordings with PS3, through fuppes and/or mediatomb upnp servers. It sort of works through transcoding PES-TS or PES-PS, but it feels slow and jerky when compared to formats natively supported by PS3.. Anyway, there have been articles about vdr supporting TS recording at some point, how is this going? This would be ideal for me, because mpeg-ts does work with PS3. Also I found the ts-recording patch, but this is not really a solution for me because I need to watch the same recordings with VDR as well, and it's not practical to use double space for both .ts and .vdr formats.. So VDR would need to support TS playback as well. This is actually what I am currently working on. VDR 1.7.x will soon begin using TS as its recording format. Replay of existing recordings (in PES) will, of course, be possible. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TS recordings?
Klaus Schmidinger wrote: On 05/04/08 18:18, Teemu Suikki wrote: Sorry if I'm asking FAQ's, I tried to search the old articles but there was no clear answer.. I have been trying to watch vdr recordings with PS3, through fuppes and/or mediatomb upnp servers. It sort of works through transcoding PES-TS or PES-PS, but it feels slow and jerky when compared to formats natively supported by PS3.. Anyway, there have been articles about vdr supporting TS recording at some point, how is this going? This would be ideal for me, because mpeg-ts does work with PS3. Also I found the ts-recording patch, but this is not really a solution for me because I need to watch the same recordings with VDR as well, and it's not practical to use double space for both .ts and .vdr formats.. So VDR would need to support TS playback as well. This is actually what I am currently working on. VDR 1.7.x will soon begin using TS as its recording format. Replay of existing recordings (in PES) will, of course, be possible Will old recording be converted automatically to TS if they are edited in VDR (cutting) or shall other tools be used for this? Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Single CoreAVC Patch
Dear Morfsta would you update your coreavc-patch for current HG-version of xine-lib-1.2 (btw - there's coreavc 1.7.0) I have the problem with patch # cat xine-lib-1.2hg-coreavc.diff | patch -p1 --dry-run patching file include/xine/buffer.h Hunk #2 succeeded at 687 (offset 1 line). patching file src/demuxers/bitstream.h patching file src/demuxers/demux_mpeg.c patching file src/demuxers/demux_mpeg_pes.c patching file src/demuxers/demux_qt.c Hunk #1 succeeded at 2760 (offset 34 lines). Hunk #2 succeeded at 2779 (offset 34 lines). patching file src/demuxers/demux_ts.c patching file src/libw32dll/DirectShow/DS_AudioDecoder.c patching file src/libw32dll/DirectShow/DS_Filter.c patching file src/libw32dll/DirectShow/DS_Filter.h patching file src/libw32dll/DirectShow/DS_VideoDecoder.c patching file src/libw32dll/DirectShow/guids.c patching file src/libw32dll/DirectShow/guids.h patching file src/libw32dll/DirectShow/outputpin.c patching file src/libw32dll/DirectShow/outputpin.h patching file src/libw32dll/Makefile.am The next patch would create the file src/libw32dll/nal_parser.c, which already exists! Assume -R? [n] n Apply anyway? [n] n Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file src/libw32dll/nal_parser.c.rej The next patch would create the file src/libw32dll/nal_parser.h, which already exists! Assume -R? [n] n Apply anyway? [n] n Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file src/libw32dll/nal_parser.h.rej patching file src/libw32dll/w32codec.c patching file src/libw32dll/wine/ext.c patching file src/libw32dll/wine/pe_image.c patching file src/libw32dll/wine/vfw.h patching file src/libw32dll/wine/win32.c Hunk #36 FAILED at 5288. Hunk #37 succeeded at 5327 (offset -2 lines). Hunk #38 succeeded at 5440 (offset -2 lines). Hunk #39 succeeded at 5460 (offset -2 lines). Hunk #40 succeeded at 5468 (offset -2 lines). Hunk #41 succeeded at 5481 (offset -2 lines). 1 out of 41 hunks FAILED -- saving rejects to file src/libw32dll/wine/win32.c.rej -Original Message- From: Morfsta [EMAIL PROTECTED] To: vdr@linuxtv.org Date: Fri, 15 Feb 2008 15:40:10 + Subject: [vdr] [ANNOUNCE] Single CoreAVC Patch that Works with Xine-lib andVdr-xine Hi, Attached is a patch to enable decoding of H264 video streams using the CoreAVC Win32 DLL, the latest HG clone of xine-lib and Reinhard's vdr-xine and of course VDR. CoreAVC is a commercial and fast software-based H264 decoder. To make this work: - 1) Download the latest mercurial xine-lib (hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2) 2) Patch it (cd xine-lib-1.2 ; patch -p 1 xine-lib-1.2hg-coreavc.diff) 3) Make and install it in your usual way (e.g. ./autogen.sh --disable-dxr3 ; make ; make install). You might want to remove old xine-lib first (rm /usr/local/lib/libxine* ; rm -rf /usr/local/lib/xine) 4) Make and install xine-ui (skip if already installed) 5) mkdir /usr/lib/win32 6) Put CoreAVCDecoder.ax (version 1.5.0 is the only version I can get working - the version I have is called coreavcdecoder_unpacked.ax) in /usr/lib/win32 7) Remove the old external ff decoder references (rm /usr/local/lib/xine/plugins/2.0/xineplug_decode_ff.so ; rm /usr/local/lib/xine/plugins/2.0/xineplug_decode_qt.so) 8) Start VDR -Pxine 9) Run xine (xine -f -pq -I -V xv -A alsa --post vdr_video --post vdr_audio -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 vdr://tmp/vdr-xine/stream#demux:mpeg_pes) You can also tweak some of the CoreAVC settings. See this page for more details: - http://code.google.com/p/coreavc-for-linux/wiki/RegisterCoreAVC but change ~/.mplayer/registry32 with ~/.xine/win32registry. Note, to increase performance I have disabled the xine de-interlacer for H264 streams as by default the CoreAVC deinterlacer is enabled. I don't think it's as good as the xine de-interlacer, but if you want to try re-enable xine deint on your CPU (too slow on my 2.6Ghz dual core) then edit xine's src/libw32dll/w32codec.c and re-enable int field = VO_BOTH_FIELDS | VO_INTERLACED_FLAG; and comment out int field = VO_BOTH_FIELDS; Then you can disable CoreAVC's deinterlacer using the instructions on code.google.com (registercodec -r ~/.xine/win32registry -k HKEY_CURRENT_USER\\Software\\CoreCodec\\CoreAVC Pro\\Deinterlace -v 3 -t dword) Note, I haven't written the majority of this patch, it has been pulled together from about 4 other patches (budice's work on DVBN and the google code site itself). I have added code to automatically detect the size of the H264 stream and to set the aspect ratio of the resultant picture as well as making it apply cleanly (hopefully!) to today's HG of xine. Therefore, the code is nothing more than a total hack and will not likely see inclusion in xine in it's current form. There is currently H264 parsing occurring in the demuxer which is probably a bad thing, it should be moved out of there.
[vdr] error decompressing frame for Astra HD+
Hi during watching of Astra HD+ from Astra 19,2E I always have this errors [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]B picture before any references, skipping [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]no frame! ffmpeg_video_dec: error decompressing frame [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]non existing PPS referenced [h264 @ 0xabfba3d0]decode_slice_header error [h264 @ 0xabfba3d0]no frame! ffmpeg_video_dec: error decompressing frame 200 frames delivered, 31 frames skipped, 52 frames discarded video_out: throwing away image with pts 120676128 because it's too old (diff : 25806). video_out: throwing away image with pts 120690172 because it's too old (diff : 43300). video_out: throwing away image with pts 120711478 because it's too old (diff : 73586). vdr: osdflush: n: 4, 76.7, timeout: 0, result: 0 video_out: throwing away image with pts 120732839 because it's too old (diff : 104127). I think it's ffmpeg's problem, but I don't know how can I solve it. It seems to me, nobody from ffmpeg-devel list doesn't want to fix it. Has somebody experience with this problem ? Igor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] error decompressing frame for Astra HD+
On Sun, May 04, 2008 at 11:13:37PM +0400, Igor wrote: I think it's ffmpeg's problem, but I don't know how can I solve it. It seems to me, nobody from ffmpeg-devel list doesn't want to fix it. Has somebody experience with this problem ? The Astra HD stream has errors always on the same positions in the loop. They show up also with the Reel HDE and the Humax HD1000. When they were simulcasting AstraHD on the Pro7HD and PremiereHD-transponder, only the stream on the PremiereHD-transponder was OK. Now they apparently have moved the faulty stream also to PremiereHD... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TS recordings?
Klaus Schmidinger wrote: On 05/04/08 19:29, Pasi Juppo wrote: Klaus Schmidinger wrote: On 05/04/08 18:18, Teemu Suikki wrote: Sorry if I'm asking FAQ's, I tried to search the old articles but there was no clear answer.. I have been trying to watch vdr recordings with PS3, through fuppes and/or mediatomb upnp servers. It sort of works through transcoding PES-TS or PES-PS, but it feels slow and jerky when compared to formats natively supported by PS3.. Anyway, there have been articles about vdr supporting TS recording at some point, how is this going? This would be ideal for me, because mpeg-ts does work with PS3. Also I found the ts-recording patch, but this is not really a solution for me because I need to watch the same recordings with VDR as well, and it's not practical to use double space for both .ts and .vdr formats.. So VDR would need to support TS playback as well. This is actually what I am currently working on. VDR 1.7.x will soon begin using TS as its recording format. Replay of existing recordings (in PES) will, of course, be possible Will old recording be converted automatically to TS if they are edited in VDR (cutting) or shall other tools be used for this? I'm currently not planning on automatically converting old recordings. However, if an external tool converts existing PES recordings to TS, VDR should be able to play them. I assume that this will mean also that old recordings cannot be edited with new VDR unless it contains also support for PES editing, correct? Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TS recordings?
On 05/04/08 22:27, Pasi Juppo wrote: Klaus Schmidinger wrote: On 05/04/08 19:29, Pasi Juppo wrote: Klaus Schmidinger wrote: On 05/04/08 18:18, Teemu Suikki wrote: Sorry if I'm asking FAQ's, I tried to search the old articles but there was no clear answer.. I have been trying to watch vdr recordings with PS3, through fuppes and/or mediatomb upnp servers. It sort of works through transcoding PES-TS or PES-PS, but it feels slow and jerky when compared to formats natively supported by PS3.. Anyway, there have been articles about vdr supporting TS recording at some point, how is this going? This would be ideal for me, because mpeg-ts does work with PS3. Also I found the ts-recording patch, but this is not really a solution for me because I need to watch the same recordings with VDR as well, and it's not practical to use double space for both .ts and .vdr formats.. So VDR would need to support TS playback as well. This is actually what I am currently working on. VDR 1.7.x will soon begin using TS as its recording format. Replay of existing recordings (in PES) will, of course, be possible Will old recording be converted automatically to TS if they are edited in VDR (cutting) or shall other tools be used for this? I'm currently not planning on automatically converting old recordings. However, if an external tool converts existing PES recordings to TS, VDR should be able to play them. I assume that this will mean also that old recordings cannot be edited with new VDR unless it contains also support for PES editing, correct? VDR will be able to edit PES recordings just as it is right now. The cutter code doesn't care if the actual recording is PES or TS. Except maybe for the cRemux::SetBrokenLink() call - but I'll cross that bridge when I get there... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
