[vdr] Subtitles not shown after language change
Hi, I noticed a problem with multi-language broadcast with subtitles or actually playback of recording of that (I didn't watch it in live). The clip is mainly having swedish audio, but during the interviews audio is finnish. However audio track seems to marked as swedish only. During the swedish audio the clip has finnish subtitles and vice versa. But during the playback when finnish subtitles should be shown again after swedish, they will not appear. Only way to fix that is to stop the playback and press play again and then the finnish subtitles are shown again. I noticed that subtitle menu shows that actually finnish subtitles might be in swedish track for a while. But still, if I stop and then continue the playback, VDR shows the subtitles, so I'm not sure where the problem is. I uploaded the 100MB sample clip to here: http://rapidshare.com/files/143391850/Sportmagasinet.tgz.html My system consists from VDR 1.6.0-1 on FC4, TechnoTrend DVB-C FF 2.1+Satelco DVB-C budget. Default languages are set as Finnish, Swedish and English in that order for subtitles and Finnish, English, Swedish for audio. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with audio sync in playback
On 14.10.2006 23.20, "Pasi Juppo" <[EMAIL PROTECTED]> wrote: > This problem is yet to be fixed to my understanding. Now I have a good > recording (one episode from Lost) where this happens very often. The > problem seems to be related to situations where the scene fades black > before new scene. There is something strange in those situations.. > > If someone has the knowledge/talent to start debugging the problem I can > put the recording available for downloading. Well, I don't have knowledge for debugging, but I ran some tests. I took few minutes crop from a recording of same episodes and tried it with different AV7110 firmwares. (TT DVB-C FF 2.1 card) I tested with VDR 1.4.3 and test_av app included in 22623 test firmware package, with firmwares 261a, 261f, 2622 and that test version 22623. Everytime playback stuttered and lost a/v sync after scene change situation. So I think this is more like dvb firmware/driver problem than VDR problem. However this is very annoying. -- Tero Siironen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On 20.10.2006 15.09, "Klaus Schmidinger" <[EMAIL PROTECTED]> wrote: > C.Y.M wrote: >> Since it has been several years now and I have never been able to solve the >> a/v >> desync issues with my Nexus-S FF card when playing back recordings... > > I'm replaying many recordings (actually most of what I watch > are recordings ;-) and don't even remember when was the last > time I had an A/V desync. > > Are you getting this with recordings from particular channels, > or does it happen all the time? > Also, is this with MPEG audio or AC3? Well here in Finland the channels at least where I've seen this to happen are two commercial channels (MTV3 and Nelonen). I don't remember seeing those problems with non-commercial channels (YLE's channels). The a/v sync problems usually occur when commercial break ends and program continues. But it happens also in the spots where there has been commercial break in the original broadcast but not in here. However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these. I preserved an example clip of this with length of 3 minutes and there is four desync spots in it. So it is not directly related to commercial breaks. I think this happens almost on every recording made from these two channels. Audio is normal MPEG. -- Tero Siironen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On 21.10.2006 15.58, "Oliver Endriss" <[EMAIL PROTECTED]> wrote: > Udo Richter wrote: >> Tero Siironen wrote: >>> However, like Pasi Juppo told earlier in other thread, in last weeks episode >>> of Lost there was many fadeout-fadeins between scenes and a/v desync >>> happened on every one of these. >> >> I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade >> into black, the data stream seems to get stuck, frames get delayed, and >> as consequence A/V desyncs and playback gets jerky, with lots of audio >> and video frame drops. This can be fixed by pausing and jumping a few >> frames backwards. >> >> My theory is that since audio is typically 600ms ahead of video, maybe >> the audio buffers run over. Strange thing is why this happens >> reproducible on blackness. Maybe due to extremely low bit rate in this >> situation, more frames get packed into one data block, causing data flow >> to be disturbed beyond some limit. It cant be too high data rate, ATV+ >> has just 2mbit avg, 4mbit max data rate. > > Does it also occur with the latest test firmware? > http://www.suse.de/~werner/test_av-f22623.tar.bz2 > > If yes, please provide short sample clips. > Please verify that the clips are not damaged, i.e. they play fine with > mplayer or xine. > > Oliver Here is a 3 minute clip from the episode of Lost I told earlier. http://kotisivu.suomi.net/izero/lost.tar 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync - in progress?
On 19.1.2007 22:30, "Oliver Endriss" <[EMAIL PROTECTED]> wrote: > Oliver Endriss wrote: >> Marco Skambraks wrote: >>> hi, >>> >>> are there any new information about the FF a/v sync problem? >>> is the firmware development still in progress? >> >> Sorry, no success yet. > > Werner fixed the A/V sync problem. Please test firmware f12623. > See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692 > > Oliver I can also report A/V sync working, but also problem that might relate to this new test version of the firmware. Timer recording failed, because vdr couldn't change the channel. Logs were filled with entries below resulting recording of 0 bytes. Another two recordings earlier has worked however, so could be related or coincidence. But Wife Approval Factor just dropped dramatically :) - logs - /var/log/messages: Jan 22 19:59:21 localhost vdr: [1758] timer 1 (4 1959-2110 'Huippumalli haussa') start Jan 22 19:59:21 localhost vdr: [1758] record /video/Huippumalli_haussa/2007-01-22.19.59.99.99.rec Jan 22 19:59:21 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 b96a ret -1 handle d099 Jan 22 19:59:21 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 b96a ret -1 handle d099 Jan 22 19:59:21 localhost kernel: dvb-ttpci: av7110_fw_cmd error -1 Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0012 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=18, tid=4E, mask=FE): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0012 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=18, tid=50, mask=F0): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0012 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=18, tid=60, mask=F0): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0014 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=20, tid=70, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=0, tid=00, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0011 b96a ret -1 handle d099 Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0011 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=17, tid=42, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 0010 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=16, tid=40, mask=FF): Operation not permitted Jan 22 19:59:22 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 b96a ret -1 handle d099 Jan 22 19:59:22 localhost vdr: [1971] ERROR: can't set filter (pid=0, tid=00, mask=FF): Operation not permitted Jan 22 19:59:25 localhost kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 00d7 b96a ret -1 handle Jan 22 19:59:25 localhost vdr: [1758] ERROR (dvbdevice.c,683): Operation not permitted Jan 22 19:59:25 localhost vdr: [1758] ERROR: can't set PID 215 on device 2 Jan 22 19:59:26 localhost vdr: [1758] timer 1 (4 1959-2110 'Huippumalli haussa') stop . . . dmesg: DVB (dvb_dmxdev_filter_start): could not alloc feed DVB (dvb_dmxdev_filter_start): could not alloc feed DVB (dvb_dmxdev_filter_start): could not alloc feed . . . My Setup: P3 700MHz 256 MB RAM Technotrend DVB-C FF 2.1 + CICAM with Conax Technotrend DVB-C FF 2.1 Fedora Core 5 2.6.16-1.2157_FC5 kernel VDR 1.4.3,+streamdev,ttxtsubs,subtitles,tvonscreen,text2skin, burn,wapd,osdteletext,mp3,femon -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync - in progress?
2007/1/23, Kartsa <[EMAIL PROTECTED]>: Could this be related to some sw or hw issue? I have had this new fw for a few days now and about 20+ succesfull recordings and no failures. I've got vdr 1.4.4, burn 0.0.009, subtitles 0.4.0, femon 1.1.0, mplayer 0.9.15 and vompserver 0.2.5. And on the hw side AMD Sempron 3000+, 512MB, TT DVB-C FF 2.1, DVB-C budget, FC6, kernel 2.6.18-1.2849. Well, like I said I cannot confirm that this was because of the new firmware, and I've made two successful timer recordings on Sunday. But on the other hand this was the very first time that recording failed (excluding human errors) with my new setup, built in last July and about 1-5 recordings every week. I now updated vdr and plugins and added more error recovery to it. So we'll see. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR-on-Mac patches
I've made patches for VDR 1.4.5 and few plugins (Subtitles, streamdev and xineliboutput, softdevice) to run them on Mac OS X (10.4.8 Intel tested) Notice, VDR can only be run as client for another VDR system as there's no support for DVB devices. Server-VDR needs a streamdev-server or xineliboutput plugin which can stream the reception to the client. Patches and short instrucions can be found from here: http://kotisivu.suomi.net/izero/vdr-darwin/vdr-darwin.html -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches
2007/1/29, Rob Davis <[EMAIL PROTECTED]>: Tero Siironen wrote: > I've made patches for VDR 1.4.5 and few plugins (Subtitles, streamdev and > xineliboutput, softdevice) to run them on Mac OS X (10.4.8 Intel tested) > > Notice, VDR can only be run as client for another VDR system as there's no > support for DVB devices. Server-VDR needs a streamdev-server or > xineliboutput plugin which can stream the reception to the client. > > Patches and short instrucions can be found from here: > > http://kotisivu.suomi.net/izero/vdr-darwin/vdr-darwin.html > > Sounds really good. I will play tomorrow. How easy would it be to package up a version of, say vdr-sxfe for mac with xine incorporated? In such a way that it runs, searches for a vdr server on the local net and auto connects? I don't know how hard it would be, but idea sounds very good. One problem currently is that Xine-lib doesn't compile clean on OS X yet. Some patches exists already but they don't solve all the compiling problems. Also accelerated video out is needed to get the performance, Xshm is too heavy for everyday use. Another thing that I would like to someone dig in are the DVB-drivers for OS X by John Dalgliesh (http://www.defyne.org/dvb/driver.html) which are originally based on Linux v4l drivers. Maybe VDR could be adopted for those drivers or some kind of a wrapper could be made to get DVB device support on OS X. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches
On 29.1.2007 19:23, "Martin Wache" <[EMAIL PROTECTED]> wrote: > Hi Tero, > > Tero Siironen schrieb: >> I've made patches for VDR 1.4.5 and few plugins (Subtitles, streamdev and >> xineliboutput, softdevice) to run them on Mac OS X (10.4.8 Intel tested) >> > Funny, a friend, Stefan Rieke and me are also working on getting VDR to > run on Mac OS X. We have VDR 1.4.0 running on OS X 10.3.9 and 10.4.8, > together with a few plugins. > I think we are a bit more advanced than you, we have a special version > of the softdevice which has native audio and video Mac OS X support (the > video is displayed via OpenGL), and a very alpha version of an > mminput-plugin, which makes it possible to use USB DVB devices on Mac OS > X together with the VDR. > However after a short look you patches to VDR seem to be cleaner than > ours ;-) Hi Martin, Well this is good news as I was hopingd that someone could continue developing this as personally I don't have too much spare time. I started this just to test what is required to get VDR even compiled. Because it wasn't so much, I continued also with few plugins to get also video out and used Xineliboutput for it. If there's any use of my patches please use them. I can provide at least test support for Mac-VDR. > We planned to publish our work some time ago, but up to now we delayed > it again and again... > Maybe we can join our efforts? If you are interested, you (or anyone > else...) can find our special softdevice version at > > http://butler.physik.uni-mainz.de/~wache/softdevice-macosx.tbz > > We developed it using a PowerPCs, so there might be some endian problems > on Intel Systems. The package also contains short instructions how to > build the softdevice and ffmpeg. I tried the softdevice plugin but it failed on shmget. I have larger shm values in /etc/rc than in the ReadMe, any ideas what could be the problem: Vdr start output: [softdevice] initializing Plugin [softdevice] Initializing Video Out [softdevice] ffmpeg build(3349248) cShmVideoOut: Got ctl_shmid 65536 shm ctl! [softdevice] Subplugin successfully opend [softdevice] Video Out seems to be OK [softdevice] Initializing Audio Out [softdevice] No alsa support compiled in. Using dummy-audio [softdevice] Audio out seems to be OK [softdevice] A/V devices initialized, now initializing MPEG2 Decoder Client start output: cQuartVideoOut [vout-quartz] WindowEventHandler result 0 [vout-quartz] resized.. dsyslog:[VideoOut]: 720x536 [0,0 720x536] -> 360x288 [0,12 360x263] [vout-quartz] result 0 init video engine [vout-quartz] initgl Finished Quartz constructor ctl_shmid error in shmget! Check if the Vdr is running with the softdevice and the option "-vo shm:"! [vout-quartz] cQuartzVideoOut destructor [vout-quartz] RmShmMemory pic 655361 osd 655362 dsyslog:[VideoOut]: Good bye Mac OS X 10.4.8 running on 15" MacBook Pro 2.33 GHz Core 2 Duo, 2GB RAM, 160GB HDD -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches
2007/1/29, Klaus Schmidinger <[EMAIL PROTECTED]>: Martin Wache wrote: > Hi Tero, > > Tero Siironen schrieb: >> I've made patches for VDR 1.4.5 and few plugins (Subtitles, streamdev and >> xineliboutput, softdevice) to run them on Mac OS X (10.4.8 Intel tested) >> > Funny, a friend, Stefan Rieke and me are also working on getting VDR to > run on Mac OS X. We have VDR 1.4.0 running on OS X 10.3.9 and 10.4.8, > together with a few plugins. > I think we are a bit more advanced than you, we have a special version > of the softdevice which has native audio and video Mac OS X support (the > video is displayed via OpenGL), and a very alpha version of an > mminput-plugin, which makes it possible to use USB DVB devices on Mac OS > X together with the VDR. > However after a short look you patches to VDR seem to be cleaner than > ours ;-) > > We planned to publish our work some time ago, but up to now we delayed > it again and again... > Maybe we can join our efforts? If you are interested, you (or anyone > else...) can find our special softdevice version at > > http://butler.physik.uni-mainz.de/~wache/softdevice-macosx.tbz > > We developed it using a PowerPCs, so there might be some endian problems > on Intel Systems. The package also contains short instructions how to > build the softdevice and ffmpeg. A few months ago I have received a patch that adapts VDR to the Mac from Andreas Thiede (a.thiede at berlin dot de), but haven't had time to really look into it yet (shame on me - I'm permanently out of time...). Don't know if he's working with any of you. Anyway, if this is supposed to go into the main VDR source one day, it might be best if you join forces and agree on common solution. I would appreciate if the impact on the VDR source could be kept to a minimum by putting everything as far as possible into a separate compat.[hc] and avoiding tons of "#ifdef __APPLE__" all over the place. I agree. These patches I made on purpose that way that it has those conditional compilings, so everyone could see what has been changed as it makes the bug hunting easier. Non-standard C funtion replacements I placed in darwinutils.[hc]. I think that almost all of the modifications can be put in a own file. Exception would be isnumber function in tools and of course includes. Function with 'isnumber' name is already defined* in Darwin, so that name needs a change if Darwin compatibility without code changes is desired. Maybe this could be made in developer version at some point. *) I should check what the definition for that really is. I got error that it wasn't compatible, so I just changed the name. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches
On 30.1.2007 00:58, "Martin Wache" <[EMAIL PROTECTED]> wrote: > Hmm, you can check with ipcs if the shared memory block has properly > been created, has the correct Id (it should be the one in shm-common.h), > and has the correct size. If you end the vdr, the block won't be > deleted, so you may try to delete the shared memory block and let vdr > create a new one. Did you make sure that you have a clean build (make > clean doesn't delete all the files...)? Ok, there obviously was some files left when compiling because now when I'm trying to compile from clean environment I get: Plugin softdevice: g++ -O2 -g -Wall -fPIC -Woverloaded-virtual -c -DHAVE_CONFIG -DPOWERPC -DNO_LINUX -DPLUGIN_NAME_I18N='"softdevice"' -D_GNU_SOURCE -DPLUGINLIBDIR='"./PLUGINS/lib"' -DMACOSAO_SUPPORT -DQUARTZ_SUPPORT -DSHM_SUPPORT -I../../../include -I../../../../DVB/include -I/sw/include -I/sw/include/ffmpeg softdevice.c /sw/include/ffmpeg/avformat.h:243: warning: 'AVFrac' is deprecated (declared at /sw/include/ffmpeg/avformat.h:94) /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.fram ework/Headers/MachineExceptions.h:245: error: declaration does not declare anything make[1]: *** [softdevice.o] Error 1 However, before I cleaned it I tried ipcs with some debug. Key was correct, but for some reason shmget returned always -1. I hardcoded the correct value to ctl_shmid (from softdevice's output while vdr was running) and got the window show up with green picture, but softdevice didn't react to that. I then installed same setup to my iBook G4 and managed to get picture and sound but not able to control the window or vdr. Is this how it should be at the moment? -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches
On 30.1.2007 21:39, "Martin Wache" <[EMAIL PROTECTED]> wrote: > Did you start the client like it is described in the ReadMe? From inside > of the McVdrClient.app folder? For some reason Quartz application needs > the context of this folder to run correctly. I don't know if there is a > workaround... Argh, my mistake. It is working now. But the problem now lies on remote setup. Every keypress is detected as same key and therefore remote cannot be setup. The window with McVdrClient shows different keycodes, but vdr doesn't detect it. Same thing if keyboard is tried, so something is wrong, but I cannot find out what it is. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches
On 30.1.2007 23:02, "Martin Wache" <[EMAIL PROTECTED]> wrote:
> Tero Siironen schrieb:
>> On 30.1.2007 21:39, "Martin Wache" <[EMAIL PROTECTED]> wrote:
>>
>>> Did you start the client like it is described in the ReadMe? From inside
>>> of the McVdrClient.app folder? For some reason Quartz application needs
>>> the context of this folder to run correctly. I don't know if there is a
>>> workaround...
>>
>> Argh, my mistake. It is working now. But the problem now lies on remote
>> setup. Every keypress is detected as same key and therefore remote cannot be
>> setup. The window with McVdrClient shows different keycodes, but vdr doesn't
>> detect it. Same thing if keyboard is tried, so something is wrong, but I
>> cannot find out what it is.
>>
>
> This somehow sounds familiar... but I can't remember the circumstances.
> But it should be simple to add a few printfs to narrow the problem down.
> The key events are recieved by KeyEventHandler() in video-quartz.c
> (and there the printouts are written, note that only the first value is
> actually used). quartzRemote->PutKey() is the one in McVdrClient.c, it
> should write the keycode into the shared memory control block and signal
> the softdevice.
>
> Forget it - I think I know now whats wrong, there is a patch missing in
> your vdr. See remote.c, if I remember correctly the format string is not
> correctly interpreted by the printf. Here is my cRemote::Put() method:
>
>
> bool cRemote::Put(uint64 Code, bool Repeat, bool Release)
> {
> char buffer[32];
> snprintf(buffer, sizeof(buffer), "%0llX", Code);
> //snprintf(buffer, sizeof(buffer), "%016LX", Code);
> return Put(buffer, Repeat, Release);
> }
Thank you, that was it. Next thing I'll try to do is get it to run on
MacBook Pro also.
--
Tero
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR recording speeds up during playback
I'm posting this now on this list, because got no reaction from dvb-list. I noticed a weird problem with last weeks Mythbusters episode VDR recording. The playback suddenly speeded up like fastforward and it is repeatable. I've seen this once earlier also, but thought that it was caused by bad reception, but this time the were no visible errors on the recording. Here's the clip (22MB): http://kotisivu.suomi.net/izero/mythbusters.tar Tested with VDR 1.4.5 and firmware versions 261a, 261f, 2622 and F12623 testversion (normally in use). Not repeatable when played with VLC on OS X. My Setup: P3 700MHz 256 MB RAM Technotrend DVB-C FF 2.1 + CICAM with Conax Technotrend DVB-C FF 2.1 Fedora Core 5 2.6.16-1.2157_FC5 kernel VDR 1.4.5,+streamdev,ttxtsubs,subtitles,tvonscreen,text2skin, burn,wapd,osdteletext,mp3,femon -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR stops replay due to strong wind condition
In my case driver/firmware problems does cause some problems with FF cards every now and then (usually black screen after boot), but instead of restarting vdr from itself by watchdog, I've made an error monitor script, that monitors syslog, restarts vdr and reloads drivers when error is seen there. This way I get faster reload when needed and can keep watchdog relatively long for some plugins that may cause high load for longer times (had some problems with burn plugin and shorter watchdog time). -- Tero 2007/3/19, Andreas Mair <[EMAIL PROTECTED]>: Hi! On Sunday 18 March 2007 17:45, Heikki Manninen wrote: > On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote: > > You can disable all the cThread::EmergencyExit() calls if you don't > > want this. Maybe I should disable this by default in a future version - > > and wait until people start complaining because recordings are > > broken... ;-) > > I personally don't believe/experience that driver problems cause broken > recordings nowadays or have been causing them in the past year or two. I don't know who's fault it is but I would have broken recordings if there would be no emergency exit. It doesn't happen often, but most of the time (or always?) I get "unknown picture type" or "video datastream broken" errors if following conditions are met: - EPG scan ON - VDR runs some time before recording starts. E.g. when replaying a recording and an EPG scan has been performed before starting recording. I never have that problem if EPG scan is off. My VDR box has to FF DVB-s cards and it happened with different VDR (atm 1.4.6), kernel (atm 2.6.18.6), dvb driver (atm Friday's "refactoring" repository) and firmware (atm F12623) releases. So emergency exit is needed on my box, but I would prefer to have the cause for UPT and VDSB fixed ;) Regards, Andreas -- http://andreas.vdr-developer.org --- VDRAdmin-AM VDR user #303 ___ 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] VDR stops replay due to strong wind condition
2007/3/19, martin <[EMAIL PROTECTED]>: Maybe Tero's can give us more input of his error handling script. This sounds a more reasonable way of handling exceptions. Well basically it is quite simple, but I don't know how well it suites other drivers than dvb-ttpci/av7110. I've configured vdr as a service which loads/unloads dvb modules and starts/stops vdr. When vdr is started also this small monitor script is started. Content of monitor script in pseudocode: put last 30 lines of syslog to tempfile check for errorlines of tempfile with grep if errorline found then service vdr restart exit else sleep 30 Currently I have following patterns specified as errorlines: 'dvb-ttpci: StopHWFilter error' 'dvb-ttpci: StartHWFilter error' 'av7110_send_fw_cmd error' -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches; any more progress
Hi, 2007/3/26, Torgeir Veimo <[EMAIL PROTECTED]>: I'm trying both VDR on Mac approaches, Tero Siironens approach ends on g++ -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DLIRC_DEVICE= \"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR= \"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -I/sw/include dvbdevice.c /sw/include/linux/dvb/video.h:118: error: '__s32' does not name a type /sw/include/linux/dvb/video.h:161: error: expected ';' before '*' token /sw/include/linux/dvb/video.h:194: error: expected ';' before '*' token dvbdevice.c: In member function 'virtual void cDvbDevice::StillPicture (const uchar*, int)': dvbdevice.c:1154: error: too many initializers for 'video_still_picture' dvbdevice.c:1154: error: invalid conversion from 'char*' to 'int32_t' dvbdevice.c:1160: error: too many initializers for 'video_still_picture' dvbdevice.c:1160: error: invalid conversion from 'char*' to 'int32_t' make: *** [dvbdevice.o] Error 1 - when making in the VDR directory. I had to make a symlink from videodev_mac.h to videodev_darwin.h, since I don't have the latter (was the dvb-includes-patch.diff patch supposed to create it?), and also create an empty /sw/include/linux/compiler.h file. Yes, my mistake, it should be videodev_darwin.h instead of videodev_mac.h. I updated the dvb-patch. However I think that I don't have compiler.h file located there, so there is some differences in the environment maybe. Actually I was testing the vdr again yesterday, but had some problems so I gave up, but I will do it today and try to find out what might be your problem there. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches; any more progress
On 26.3.2007 15:52, "Torgeir Veimo" <[EMAIL PROTECTED]> wrote: > > On 26 Mar 2007, at 06:57, Tero Siironen wrote: > >> Hi, >> >> 2007/3/26, Torgeir Veimo <[EMAIL PROTECTED]>: >>> I'm trying both VDR on Mac approaches, Tero Siironens approach >>> ends on >>> >>> g++ -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DLIRC_DEVICE= >>> \"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR= >>> \"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -I/sw/include dvbdevice.c >>> /sw/include/linux/dvb/video.h:118: error: '__s32' does not name a >>> type >>> /sw/include/linux/dvb/video.h:161: error: expected ';' before '*' >>> token >>> /sw/include/linux/dvb/video.h:194: error: expected ';' before '*' >>> token >>> dvbdevice.c: In member function 'virtual void >>> cDvbDevice::StillPicture >>> (const uchar*, int)': >>> dvbdevice.c:1154: error: too many initializers for >>> 'video_still_picture' >>> dvbdevice.c:1154: error: invalid conversion from 'char*' to 'int32_t' >>> dvbdevice.c:1160: error: too many initializers for >>> 'video_still_picture' >>> dvbdevice.c:1160: error: invalid conversion from 'char*' to 'int32_t' >>> make: *** [dvbdevice.o] Error 1 >>> >>> - when making in the VDR directory. I had to make a symlink from >>> videodev_mac.h to videodev_darwin.h, since I don't have the latter >>> (was the dvb-includes-patch.diff patch supposed to create it?), and >>> also create an empty /sw/include/linux/compiler.h file. >> >> Yes, my mistake, it should be videodev_darwin.h instead of >> videodev_mac.h. I updated the dvb-patch. However I think that I don't >> have compiler.h file located there, so there is some differences in >> the environment maybe. > > Ok, my /sw/include/linux/compiler.h looks like > > typedef __signed__ int __s32; > > #define __user > > So now I've managed to compile vdr (had to sort out some lib paths > manually). I'll have a look at streamdev and softdevice later tonight. I think that you might have different version of dvb-driver package or someting like that, because there's no such type (__s32) on my environment. I updated the patches to work on latest versions and corrected also dependency to libjpeg, so that it doesn't need to be symlinked anymore. Detailed instructions are now also available. http://kotisivu.suomi.net/izero/vdr-darwin/vdr-darwin.html -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches; any more progress
On 26.3.2007 04:28, "Torgeir Veimo" <[EMAIL PROTECTED]> wrote: > Using Martin Waches approach ends on > > Vigor10:~/java/src/vdr-1.4.6/PLUGINS/src/softdevice torgeir$ ./ > configure --with-ffmpeg-path ~/java/src/ffmpeg/ --disable-subplugins > ffmpeg path set to: /Users/torgeir/java/src/ffmpeg/ > Testing system and cpu type... found Darwin on i386 cpu. > Checking for pkg-config... Found. > Checking for ffmpeg... Not found. > No usable ffmpeg library found in /Users/torgeir/java/src/ffmpeg/. > Specify the path to your ffmpeg installation using --with-ffmpeg-path > or use a more recent (svn) version of ffmpeg and use/install pkg-config. > For details check config.log. > > I even tried to override the ffmpeg check, fixing a few deps (include/ > dvb/dmx.h etc), but the compilation ends on > > /Users/torgeir/java/src/ffmpeg//libavformat/avformat.h: In function > 'void av_init_packet(AVPacket*)': > /Users/torgeir/java/src/ffmpeg//libavformat/avformat.h:66: error: > 'INT64_C' was not declared in this scope > /Users/torgeir/java/src/ffmpeg//libavformat/avformat.h: At global scope: > /Users/torgeir/java/src/ffmpeg//libavformat/avformat.h:284: warning: > 'AVFrac' is deprecated (declared at /Users/torgeir/java/src/ffmpeg// > libavformat/avformat.h:118) > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/MachineExceptions.h:245: error: > declaration does not declare anything > > Are there updated patches around, or am I missing something > important? I'm trying this on a macbook pro with the relevant X11 and > fink environment. The later error is also what I get here. It doesn't happen on PPC OS X and it is related to X11, but I haven't been able to find the fix for it yet. VTK has had something similar: http://www.vtk.org/Bug/bug.php?op=show&bugid=3233 -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches; any more progress
2007/4/25, Rob Davis <[EMAIL PROTECTED]>: Torgeir Veimo wrote: > > On 24 Apr 2007, at 22:54, Rob Davis wrote: > >> Sorry to bring to life an old thread, but does anyone have a working >> copy of vdr-sxfe for osx? Pref PPC, but intel would work too.. Maybe a >> list of dependencies too? >> >> My VDR server is a headless box, but I want to use the Mac with OsX >> instead of Gentoo to watch VDR... > > Get the vdr on mac patches posted to the list earlier. You want to have > fink installed to get ffmpeg etc. The patches for softdevice are already > in CVS, with instructions and dependencies. They should be fairly up to > date, but just ask questions here when you're stuck.. You have to use > the shm softdevice client, since there are threading issues with using > softdevice directly with quartz output. > I'm not sure that'll work for me as the DVB device is on another machine. I want to run just a display viewer over the network. Mac version is currently for cases just like this. It doesn't support DVB devices (at least yet). So just like Torgeir told, you need to install streamdev for both ends. The problem with Intel machines is that the video screen is green-purple. I've not found out what the problem is. If you are using Intel Mac you need also small change to video-quartz.h to get it compile. See the softdevice patch in the page below. PPC should work straight out ot CVS. http://kotisivu.suomi.net/izero/vdr-darwin/vdr-darwin.html -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-on-Mac patches; any more progress
On 27.4.2007 12:11, "Torgeir Veimo" <[EMAIL PROTECTED]> wrote: > > On 27 Apr 2007, at 06:59, Tero Siironen wrote: > >> The problem with Intel machines is that the video screen is green- >> purple. > > http://lists.berlios.de/pipermail/softdevice-devel/2007q2/002828.html > > I get correct colors with that change. Thanks, now it's working great. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.5.10, Subtitles gets out of sync
Great that the subtitles are now part of the VDR. Unfortunately, there seems to be some problems still. I tested this new VDR version for some minutes and noticed that some subtitles were shown too late in live tv watching. I didn't check how the timing of subtitles is done, but it seemed that VDR missed one "sync-point" and after that all the subtitles were shown one "sync-point" too late. Channel change seemed to correct the situation for a while. Similar problem was seen on two channels, so I think that the broadcast was ok in this case. Also, I haven't seen similar problems earlier with subtitles-plugin. I didn't notice this kind of error either when viewing recordings made with subtitles-plugin. I didn't test yet if the problem can be seen also with recordings made with 1.5.10, but I think I can test that later today. Testing was done with VDR 1.5.10 without any plugins, TT FF 2.1 DVB-C card and YLE 2 and YLE Teema channels here in Finland. Anyone else seen this kind of problems? -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.10, Subtitles gets out of sync
2007/10/17, Rolf Ahrenberg <[EMAIL PROTECTED]>: > Another minor problem I've noticed few times is a picture freeze for a > second. This is a new feature on my setup after VDR's integrated > subtitling and the freeze has happen always on channels with DVB > subtitles... I noticed this also once and actually got it into recording also, playback freezed for a second always at that certain point. But unfortunately I have deleted the recording already. It was also program with DVB subtitles. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
Hi, I upgraded from VDR 1.4.7 to 1.5.17 and noticed that some of my old recordings won't play decently with this new version. Here's a syslog entry and example clip can be found from http://kotisivu.suomi.net/izero/vdr-darwin/ddmode_example.zip (9MB) Those problematic recordings were done with some 1.3.x series VDR with ttxtsubs plugin in fall 2004. Plays fine with VDR 1.4.7, but playback stutters when playing with VDR 1.5.17. My system has DVB-C FF 2.1 and DVB-C budget cards. Running on Fedora 5. Mar 4 11:40:28 zvdr vdr: [5601] replay /video/%%Phone_Booth/ 2004-10-31.22.59.50.99.rec Mar 4 11:40:28 zvdr vdr: [5601] playing '/video/%%Phone_Booth/ 2004-10-31.22.59.50.99.rec/001.vdr' Mar 4 11:40:28 zvdr vdr: [5601] loading /video/%%Phone_Booth/ 2004-10-31.22.59.50.99.rec//marks.vdr Mar 4 11:40:28 zvdr vdr: [5601] ttxtsubs: teletext subtitles replayer started with initial page 000 Mar 4 11:40:28 zvdr vdr: [6338] live subtitle thread ended (pid=5601, tid=6338) Mar 4 11:40:28 zvdr vdr: [5601] buffer stats: 0 (0%) used Mar 4 11:40:28 zvdr vdr: [6401] dvbplayer thread started (pid=5601, tid=6401) Mar 4 11:40:28 zvdr vdr: [6402] non blocking file reader thread started (pid=5601, tid=6402) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 72 (counter is at 0) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = B5 (counter is at 1) Mar 4 11:40:28 zvdr vdr: [6403] subtitleConverter thread started (pid=5601, tid=6403) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 71 (counter is at 1) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = CB (counter is at 2) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = D4 (counter is at 3) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 93 (counter is at 3) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 5C (counter is at 4) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 02 (counter is at 5) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = E0 (counter is at 6) Mar 4 11:40:28 zvdr vdr: [6401] setting audio track to 1 (0) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = B5 (counter is at 7) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 08 (counter is at 8) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = FC (counter is at 9) Mar 4 11:40:28 zvdr vdr: [6401] switching to pre 1.3.19 Dolby Digital compatibility mode - substream id = FC Mar 4 11:40:28 zvdr vdr: [6341] TS buffer on device 1 thread ended (pid=5601, tid=6341) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = FC (counter is at 0) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 0D (counter is at 1) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 99 (counter is at 2) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 5F (counter is at 2) Mar 4 11:40:28 zvdr vdr: [6339] buffer stats: 3196 (0%) used Mar 4 11:40:28 zvdr vdr: [6339] receiver on device 1 thread ended (pid=5601, tid=6339) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 02 (counter is at 3) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 0C (counter is at 4) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = FB (counter is at 5) Mar 4 11:40:28 zvdr vdr: [6401] setting audio track to 1 (0) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 9B (counter is at 6) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 58 (counter is at 6) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = C4 (counter is at 7) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = E1 (counter is at 8) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = BB (counter is at 9) Mar 4 11:40:28 zvdr vdr: [6401] switching to pre 1.3.19 Dolby Digital compatibility mode - substream id = BB Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = BB (counter is at 0) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 14 (counter is at 1) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 01 (counter is at 2) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 66 (counter is at 3) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = B4 (counter is at 4) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 5D (counter is at 5) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = DA (counter is at 5) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 5B (counter is at 5) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = BE (counter is at 6) Mar 4 11:40:28 zvdr vdr: [6401] unknown PS1 packet, substream id = 6C (counte
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
Rolf Ahrenberg kirjoitti 5.3.2008 kello 23.11: > On Wed, 5 Mar 2008, Klaus Schmidinger wrote: > >> On 03/04/08 10:58, Tero Siironen wrote: >>> >>> Those problematic recordings were done with some 1.3.x series VDR >>> with >>> ttxtsubs plugin in fall 2004. Plays fine with VDR 1.4.7, but >>> playback >>> stutters when playing with VDR 1.5.17. My system has DVB-C FF 2.1 >>> and >>> DVB-C budget cards. Running on Fedora 5. >> >> My guess would be that the offending data comes from the ttxtsubs >> plugin. >> Maybe you need to patch VDR to become aware of this. > > The ttxtsubs patch should strip off all EBU teletext data packets, so > that they won't mess up the normal PES playback. Maybe Tero's setup is > missing this one... Maybe I need to make another test run with plain versions of both VDR versions when I get back to home. But anyway I have patched VDR 1.5.17 with vdr-1.5.17-ttxtsubs-0.0.5.diff and ttxtsubs 0.0.5 plugin is patched with raastinrautaedition from 22-Jan so I think patches should be ok, or is there still some more patches for ttxtsubs? 1.4.7 version of VDR is patched with similar patches (from that timeframe) and as I said it plays the recordings (and the sample) fine. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.17 - pre 1.3.19 compatibility mode problems
Rolf Ahrenberg kirjoitti 6.3.2008 kello 13.49: > On Thu, 6 Mar 2008, Tero Siironen wrote: > >> Maybe I need to make another test run with plain versions of both VDR >> versions when I get back to home. But anyway I have patched VDR >> 1.5.17 >> with vdr-1.5.17-ttxtsubs-0.0.5.diff and ttxtsubs 0.0.5 plugin is >> patched with raastinrautaedition from 22-Jan so I think patches >> should >> be ok, or is there still some more patches for ttxtsubs? 1.4.7 >> version >> of VDR is patched with similar patches (from that timeframe) and as I >> said it plays the recordings (and the sample) fine. > > Those patches should be enough and fine, so just recheck that the > vdr-1.5.17 patch is really integrated succesfully. If everything still > looks ok, I'd say there's a bug in the patch. You could debug what's > happening in the additional StripExtendedPackets function found in > dvbplayer.c. I installed plain versions of VDR and then ttxtsubs patched versions and run the tests with interesting results. plain vdr-1.4.7 plays fine plain vdr-1.5.17stutters vdr-1.4.7 with ttxtsubs patches plays fine vdr-1.5.17 with ttxtsubsstutters So it seems that something has changed in the VDR playback so that it cannot play those old recordings with or without ttxtsubs patching. I'm using TechnoTrend DVB-C FF 2.1 card with dvb-ttpci-01.fw-22623 firmware. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
Simon Baxter kirjoitti 24.4.2008 kello 10.08: Hello I have 2x DVB-C cards with Alphacrypt multi-cams. A TT-1500-C budget card and a TT-2300-C FF card and run vdr-xine. When recording one channel and attempting to watch another in the same transport stream, or trying to switch to another transport stream (and hence card) I get "channel not available" messages. After switching back and forth to other transport streams, usually I can overcome this problem. But occasionally I it won't play any channels in one specific transport stream or another. What's the best way to diagnose this? How do I enable debugging to see more info than is displayed in messages: Apr 24 18:53:56 callin vdr: [7375] switching to channel 8 Apr 24 18:53:56 callin vdr: [30940] transfer thread started (pid=7375, tid=30940) Apr 24 18:53:57 callin vdr: [30939] femon receiver thread ended (pid=7375, tid=30939) Apr 24 18:53:57 callin vdr: [30941] femon receiver thread started (pid=7375, tid=30941) Apr 24 18:53:58 callin vdr: [30940] setting audio track to 1 (0) Apr 24 18:54:04 callin vdr: [7375] switching to channel 9 Apr 24 18:54:04 callin vdr: [30940] transfer thread ended (pid=7375, tid=30940) Apr 24 18:54:04 callin vdr: [7375] buffer stats: 47564 (2%) used Apr 24 18:54:04 callin vdr: [7375] info: Channel not available! Apr 24 18:54:04 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:22 callin vdr: [7375] switching to channel 1 Apr 24 18:54:22 callin vdr: [30942] transfer thread started (pid=7375, tid=30942) Apr 24 18:54:22 callin vdr: [30936] TS buffer on device 2 thread ended (pid=7375, tid=30936) Apr 24 18:54:22 callin vdr: [30935] buffer stats: 84600 (4%) used Apr 24 18:54:22 callin vdr: [30935] receiver on device 2 thread ended (pid=7375, tid=30935) Apr 24 18:54:22 callin vdr: [30943] receiver on device 2 thread started (pid=7375, tid=30943) Apr 24 18:54:22 callin vdr: [30944] TS buffer on device 2 thread started (pid=7375, tid=30944) Apr 24 18:54:23 callin vdr: [30945] femon receiver thread started (pid=7375, tid=30945) Apr 24 18:54:23 callin vdr: [30942] setting audio track to 1 (0) Apr 24 18:54:26 callin vdr: [7375] switching to channel 9 Apr 24 18:54:26 callin vdr: [30942] transfer thread ended (pid=7375, tid=30942) Apr 24 18:54:26 callin vdr: [7375] buffer stats: 194204 (9%) used Apr 24 18:54:26 callin vdr: [7375] info: Channel not available! Apr 24 18:54:26 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:42 callin vdr: [7375] switching to channel 21 Hi, I don't know if this is same problem or not but I'm having similar symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot tune to that channel, while 1.4.7 works. As can be seen from the log, the receiving starts from couple of seconds but stops right after giving this channel not available message. My system has DVB-C 2.1 FF card and Satelco Easywatch budget card. All the other encrypted channels works ok, but this one channel has problems with VDR 1.6.0. Here's the channels.conf entry: EuroNews;GlobeCast:306000:C0M128:C:6875:2221:2232=eng,2233=deu, 2231=fra,2234=ita,2235=esl,2236=por,2237=rus,2238:768:B00:214:0:10:0 and here's the syslog: Apr 27 13:31:53 localhost vdr: [10238] cTimeMs: using monotonic clock (resolution is 999848 ns) Apr 27 13:31:53 localhost vdr: [10238] VDR version 1.6.0 started Apr 27 13:31:53 localhost vdr: [10238] codeset is 'ISO-8859-1' - known Apr 27 13:31:53 localhost vdr: [10238] found 23 locales in ./locale Apr 27 13:31:53 localhost vdr: [10238] loading /video/setup.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/sources.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/channels.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/timers.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/svdrphosts.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/remote.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/keymacros.conf Apr 27 13:31:53 localhost vdr: [10238] reading EPG data from /video/ epg.data Apr 27 13:31:53 localhost vdr: [10248] video directory scanner thread started (pid=10238, tid=10248) Apr 27 13:31:53 localhost vdr: [10249] video directory scanner thread started (pid=10238, tid=10249) Apr 27 13:31:53 localhost vdr: [10249] video directory scanner thread ended (pid=10238, tid=10249) Apr 27 13:31:53 localhost vdr: [10248] video directory scanner thread ended (pid=10238, tid=10248) Apr 27 13:31:53 localhost vdr: [10238] probing /dev/dvb/adapter0/ frontend0 Apr 27 13:31:53 localhost vdr: [10251] CI adapter on device 0 thread started (pid=10238, tid=10251) Apr 27 13:31:53 localhost vdr: [10238] probing /dev/dvb/adapter1/ frontend0 Apr 27 13:31:53 localhost vdr: [10252] tuner on device 1 thread started (pid=10238, tid=10252) Apr 27 13:31:53 localhost vdr: [10253] section handler
Re: [vdr] vdr-1.6.0 channel not available
Klaus Schmidinger kirjoitti 2.5.2008 kello 17.03: > On 04/27/08 12:49, Tero Siironen wrote: >> >> ... >> I don't know if this is same problem or not but I'm having similar >> symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot >> tune >> to that channel, while 1.4.7 works. As can be seen from the log, the >> receiving starts from couple of seconds but stops right after giving >> this channel not available message. My system has DVB-C 2.1 FF card >> and >> Satelco Easywatch budget card. All the other encrypted channels works >> ok, but this one channel has problems with VDR 1.6.0. >> > > Your CAM seems to "come and go". > Please try the 1.6.0-1 maintenance patch from > > ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff > > which increases the time between the CAM status checks. Doesn't help, log is pretty similar still and picture shows now and then for couple of seconds May 2 23:03:36 localhost vdr: [4340] VDR version 1.6.0-1 started May 2 23:03:36 localhost vdr: [4340] codeset is 'ISO-8859-1' - known May 2 23:03:36 localhost vdr: [4340] found 23 locales in ./locale May 2 23:03:36 localhost vdr: [4340] loading /video/setup.conf May 2 23:03:36 localhost vdr: [4340] loading /video/sources.conf May 2 23:03:36 localhost vdr: [4340] loading /video/channels.conf May 2 23:03:36 localhost vdr: [4340] loading /video/timers.conf May 2 23:03:36 localhost vdr: [4340] loading /video/svdrphosts.conf May 2 23:03:36 localhost vdr: [4340] loading /video/remote.conf May 2 23:03:36 localhost vdr: [4340] loading /video/keymacros.conf May 2 23:03:36 localhost vdr: [4340] reading EPG data from /video/ epg.data May 2 23:03:37 localhost vdr: [4341] video directory scanner thread started (pid=4340, tid=4341) May 2 23:03:37 localhost vdr: [4342] video directory scanner thread started (pid=4340, tid=4342) May 2 23:03:37 localhost vdr: [4340] probing /dev/dvb/adapter0/ frontend0 May 2 23:03:37 localhost vdr: [4344] CI adapter on device 0 thread started (pid=4340, tid=4344) May 2 23:03:37 localhost vdr: [4340] probing /dev/dvb/adapter1/ frontend0 May 2 23:03:37 localhost vdr: [4342] video directory scanner thread ended (pid=4340, tid=4342) May 2 23:03:37 localhost vdr: [4345] tuner on device 1 thread started (pid=4340, tid=4345) May 2 23:03:37 localhost vdr: [4346] section handler thread started (pid=4340, tid=4346) May 2 23:03:37 localhost vdr: [4348] CI adapter on device 1 thread started (pid=4340, tid=4348) May 2 23:03:37 localhost vdr: [4340] found 2 video devices May 2 23:03:37 localhost vdr: [4340] setting primary device to 1 May 2 23:03:37 localhost vdr: [4349] tuner on device 2 thread started (pid=4340, tid=4349) May 2 23:03:37 localhost vdr: [4350] section handler thread started (pid=4340, tid=4350) May 2 23:03:37 localhost vdr: [4340] assuming manual start of VDR May 2 23:03:37 localhost vdr: [4340] SVDRP listening on port 2001 May 2 23:03:37 localhost vdr: [4340] loading /video/themes/classic- default.theme May 2 23:03:37 localhost vdr: [4340] remote control LIRC - keys known May 2 23:03:37 localhost vdr: [4351] LIRC remote control thread started (pid=4340, tid=4351) May 2 23:03:37 localhost vdr: [4344] CAM 1: module present May 2 23:03:38 localhost vdr: [4341] video directory scanner thread ended (pid=4340, tid=4341) May 2 23:03:39 localhost vdr: [4340] switching to channel 1 May 2 23:03:39 localhost vdr: [4348] CAM 3: no module present May 2 23:03:39 localhost vdr: [4344] CAM 2: no module present May 2 23:03:39 localhost vdr: [4346] channel 4 (Nelonen) event Pe 02.05.2008 22:55-23:05 'IS Urheilu-uutiset' status 4 May 2 23:03:39 localhost vdr: [4346] channel 2 (YLE TV2) event Pe 02.05.2008 22:25-00:50 'Jääkiekon MM 2008: Kanada - Slovenia' status 4 May 2 23:03:39 localhost vdr: [4346] channel 6 (Sub) event Pe 02.05.2008 22:10-23:05 'Bones' status 4 May 2 23:03:39 localhost vdr: [4346] channel 3 (MTV3) event Pe 02.05.2008 22:36-01:10 'Windtalkers' status 4 May 2 23:03:39 localhost vdr: [4346] changing pids of channel 1 from 512+512:650=deu:0:2321 to 512+512:650=deu:1027=fin:2321 May 2 23:03:39 localhost vdr: [4340] retuning due to modification of channel 1 May 2 23:03:39 localhost vdr: [4340] switching to channel 1 May 2 23:03:39 localhost vdr: [4352] live subtitle thread started (pid=4340, tid=4352) May 2 23:03:39 localhost vdr: [4353] receiver on device 1 thread started (pid=4340, tid=4353) May 2 23:03:39 localhost vdr: [4354] TS buffer on device 1 thread started (pid=4340, tid=4354) May 2 23:03:40 localhost vdr: [4346] changing pids of channel 2 from 513+513:660=fin,661=sve:0:2321 to 513+513:660=fin,661=sve:2027=fin:2321 May 2 23:03:40 localhost vdr: [4346] changing pids of channel 3 from 305+305:561=fin:0:817 to 305+305:56
Re: [vdr] vdr-1.6.0 channel not available
Klaus Schmidinger kirjoitti 3.5.2008 kello 19.06: > On 05/03/08 16:24, Tero Siironen wrote: >> Klaus Schmidinger kirjoitti 2.5.2008 kello 17.03: >> >>> On 04/27/08 12:49, Tero Siironen wrote: >>>> ... >>>> I don't know if this is same problem or not but I'm having similar >>>> symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot >>>> tune >>>> to that channel, while 1.4.7 works. As can be seen from the log, >>>> the >>>> receiving starts from couple of seconds but stops right after >>>> giving >>>> this channel not available message. My system has DVB-C 2.1 FF card >>>> and >>>> Satelco Easywatch budget card. All the other encrypted channels >>>> works >>>> ok, but this one channel has problems with VDR 1.6.0. >>>> >>> Your CAM seems to "come and go". >>> Please try the 1.6.0-1 maintenance patch from >>> >>> ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff >>> >>> which increases the time between the CAM status checks. >> >> Doesn't help, log is pretty similar still and picture shows now and >> then for couple of seconds > > Looks like there are no more unexpected CAM resets, so the reason > for the > "channel not available" must be something else. Maybe the CAM doesn't > decrypt? > > You could add some debug output to cDevice::Action() to see whether > the TS packets are getting descrambled. Maybe the > TS_SCRAMBLING_TIMEOUT > needs to be increased. I will try to debug it more. The same channel works with VDR 1.4.7 so the CAM works. Also with 1.6.0-1 all other encrypted channels that I've access works with that CAM, so there is something in that one channel which causes problems with 1.6.0-1. But I will report again when I get some more data. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
