Re: [vdr] Build plugin with different headers then in VDR distribution
Thanks a lot, Clemens, for your reply. This is my mistake that I didn't explain clearly what actually I need. I use LinuxMCE (http://linuxmce.com) with integrated VDR 1.6.0. I have just VDR headers and binary. So, I can easily build any plugins which have debian patch using dpkg-buildpackage. In that case the plugins work fine. But for those which don't have that there is an only one way to build them using common way - make plugins from the VDR source directory. So, I think I can make a symlink to patched headers in the $VDR_SORUCE/include/vdr and theoretically it should work. On Mon, Sep 8, 2008 at 1:18 AM, Clemens Kirchgatterer [EMAIL PROTECTED]wrote: Michael Stepanov [EMAIL PROTECTED] wrote: what does VDR distribution mean? the vdr source code? what are you trying to achieve? i guess you have to download the desired vdr version, copy your plugins into its PLUGINS/src directory and compile them as usual. Yes, I mean VDR sources. I understand how to build plugins using headers from the VDR's sources. But in my case I have patched headers only (source is not available yet - headers only). i don't see the point. if the header files are different in respect to ABI compatibillity (for example class member order, number of members or object size) then your plugins will not work anyway. if the headers are compatible, it does not matter which one you used to compile them. anyway, vdr and plugins must be compiled with compatible header files. this is what the APIVERSION is for. you could try to copy your patched headers over a fresh vdr source tree and compile it including your plugins. hope this helps ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Cheers, Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.18 subtitles issue
On Sat, Sep 6, 2008 at 2:18 PM, matthieu castet [EMAIL PROTECTED]wrote: Klaus Schmidinger wrote: I don't have such problems here on a FF DVB card. Could it be that the softdevice plugin doesn't handle the OSD levels correctly? These were introduced in VDR version 1.5.9. Yes it seems to be a softdevice problem : there a post on the softdevice ML, the developper try something, but it didn't solve the problem. See http://thread.gmane.org/gmane.comp.video.vdr.softdevice/689 Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I see. Thanks for the information. -- Best regards, Sundararaj ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] fedora 9 vdr-1.6.0 - int no audio on channel change
Hi I've built a new fedora 9 x86_64 system (twice!) and get an intermittant problem when changing channels - no audio!! I've tried it with pvrinput analog channels, as well as digital channels via my TT-1501, TT-2300 (both with CAMs). When I change to a neighbouring channel and back again, I often get audio. Weird huh? Here's the /var/log/messages from the experience. Any ideas?? What can I try - seems like something is resetting and the audio starting with pvrinput, and nothing resetting with the TT-1501 card. HELP!!! This has been going on for months. pvrinput. 2 audio works. Change to 3, audio doesn't work. Then after 4 seconds works on it's own Sep 8 19:11:53 freddy vdr: [3108] switching to channel 2 Sep 8 19:11:53 freddy vdr: [3406] transfer thread ended (pid=3108, tid=3406) Sep 8 19:11:53 freddy vdr: [3108] buffer stats: 141000 (6%) used Sep 8 19:11:53 freddy vdr: [3407] receiver on device 10 thread ended (pid=3108, tid=3407) Sep 8 19:11:53 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:54 freddy vdr: [3410] transfer thread started (pid=3108, tid=3410) Sep 8 19:11:54 freddy vdr: [3411] receiver on device 10 thread started (pid=3108, tid=3411) Sep 8 19:11:55 freddy vdr: [3410] setting audio track to 1 (0) Sep 8 19:11:55 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:57 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:57 freddy vdr: [3108] switching to channel 3 Sep 8 19:11:57 freddy vdr: [3410] transfer thread ended (pid=3108, tid=3410) Sep 8 19:11:57 freddy vdr: [3108] buffer stats: 141752 (6%) used Sep 8 19:11:57 freddy vdr: [3411] receiver on device 10 thread ended (pid=3108, tid=3411) Sep 8 19:11:58 freddy vdr: [3414] transfer thread started (pid=3108, tid=3414) Sep 8 19:11:58 freddy vdr: [3415] receiver on device 10 thread started (pid=3108, tid=3415) Sep 8 19:11:58 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:58 freddy vdr: [3414] setting audio track to 1 (0) Sep 8 19:12:01 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:12:03 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Digital. 9 audio working. Change to 8, working. Change to 9 audio not working Sep 8 19:06:35 freddy vdr: [3108] switching to channel 9 Sep 8 19:06:35 freddy vdr: [3108] cTS2PES got 0 TS errors, 2 TS continuity errors Sep 8 19:06:35 freddy vdr: [3108] cTS2PES got 0 TS errors, 1 TS continuity errors Sep 8 19:06:35 freddy vdr: [3108] buffer stats: 58280 (2%) used Sep 8 19:06:35 freddy vdr: [3336] transfer thread started (pid=3108, tid=3336) Sep 8 19:06:35 freddy vdr: [3334] TS buffer on device 1 thread ended (pid=3108, tid=3334) Sep 8 19:06:35 freddy vdr: [] buffer stats: 58656 (2%) used Sep 8 19:06:35 freddy vdr: [] receiver on device 1 thread ended (pid=3108, tid=) Sep 8 19:06:35 freddy vdr: [3337] receiver on device 1 thread started (pid=3108, tid=3337) Sep 8 19:06:35 freddy vdr: [3338] TS buffer on device 1 thread started (pid=3108, tid=3338) Sep 8 19:06:37 freddy vdr: [3336] setting audio track to 1 (0) Sep 8 19:07:57 freddy vdr: [3336] transfer thread ended (pid=3108, tid=3336) Sep 8 19:07:57 freddy vdr: [3108] switching to channel 8 Sep 8 19:07:57 freddy vdr: [3108] buffer stats: 95692 (4%) used Sep 8 19:07:57 freddy vdr: [3344] transfer thread started (pid=3108, tid=3344) Sep 8 19:07:57 freddy vdr: [3338] TS buffer on device 1 thread ended (pid=3108, tid=3338) Sep 8 19:07:57 freddy vdr: [3337] buffer stats: 95316 (4%) used Sep 8 19:07:57 freddy vdr: [3337] receiver on device 1 thread ended (pid=3108, tid=3337) Sep 8 19:07:57 freddy vdr: [3345] receiver on device 1 thread started (pid=3108, tid=3345) Sep 8 19:07:57 freddy vdr: [3346] TS buffer on device 1 thread started (pid=3108, tid=3346) Sep 8 19:07:58 freddy vdr: [3344] setting audio track to 1 (0) Sep 8 19:08:02 freddy vdr: [3344] transfer thread ended (pid=3108, tid=3344) Sep 8 19:08:03 freddy vdr: [3108] switching to channel 9 Sep 8 19:08:03 freddy vdr: [3108] buffer stats: 62792 (2%) used Sep 8 19:08:03 freddy vdr: [3349] transfer thread started (pid=3108, tid=3349) Sep 8 19:08:03 freddy vdr: [3346] TS buffer on device 1 thread ended (pid=3108, tid=3346) Sep 8 19:08:03 freddy vdr: [3345] buffer stats: 62416 (2%) used Sep 8 19:08:03 freddy vdr: [3345] receiver on device 1 thread ended (pid=3108, tid=3345) Sep 8 19:08:03 freddy vdr: [3350] receiver on device 1 thread started (pid=3108, tid=3350) Sep 8 19:08:03 freddy vdr: [3351] TS buffer on device 1 thread started (pid=3108, tid=3351) Sep 8 19:08:04 freddy vdr: [3349] setting audio track to 1 (0) pvrinput. 2 works. Change to 3 doesn't work. Then after 4
Re: [vdr] Build plugin with different headers then in VDR distribution
Hello On Monday, 8. September 2008 Michael Stepanov wrote: Thanks a lot, Clemens, for your reply. This is my mistake that I didn't explain clearly what actually I need. I use LinuxMCE (http://linuxmce.com) with integrated VDR 1.6.0. I have just VDR headers and binary. So, I can easily build any plugins which have debian patch using dpkg-buildpackage. In that case the plugins work fine. But for those which don't have that there is an only one way to build them using common way - make plugins from the VDR source directory. So, I think I can make a symlink to patched headers in the $VDR_SORUCE/include/vdr and theoretically it should work. I started my contribution to the development of the LIVE plugin without installed vdr sources. I installed the vdr-dev package from e-tobi debian repository and used the following script to build the binary of the plugin. 'libvdr-live.so.1.6.0' is created in the .libs subdirectory then. Of course the binary had to be copied into the right installation path afterwards. #!/bin/sh # check if this are live sources # (there is an extra live subdir in the sources) [ -d live ] || exit 0 mkdir -p .libs VDRDIR=/usr/include/vdr LIBDIR=.libs make $* Kind regards Dieter Hametner -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] fedora 9 vdr-1.6.0 - int no audio on channel change
I should probably also note, I'm running vdr-xine and the audio returns if I kill xine and restart. Thanks Hi I've built a new fedora 9 x86_64 system (twice!) and get an intermittant problem when changing channels - no audio!! I've tried it with pvrinput analog channels, as well as digital channels via my TT-1501, TT-2300 (both with CAMs). When I change to a neighbouring channel and back again, I often get audio. Weird huh? Here's the /var/log/messages from the experience. Any ideas?? What can I try - seems like something is resetting and the audio starting with pvrinput, and nothing resetting with the TT-1501 card. HELP!!! This has been going on for months. pvrinput. 2 audio works. Change to 3, audio doesn't work. Then after 4 seconds works on it's own Sep 8 19:11:53 freddy vdr: [3108] switching to channel 2 Sep 8 19:11:53 freddy vdr: [3406] transfer thread ended (pid=3108, tid=3406) Sep 8 19:11:53 freddy vdr: [3108] buffer stats: 141000 (6%) used Sep 8 19:11:53 freddy vdr: [3407] receiver on device 10 thread ended (pid=3108, tid=3407) Sep 8 19:11:53 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:54 freddy vdr: [3410] transfer thread started (pid=3108, tid=3410) Sep 8 19:11:54 freddy vdr: [3411] receiver on device 10 thread started (pid=3108, tid=3411) Sep 8 19:11:55 freddy vdr: [3410] setting audio track to 1 (0) Sep 8 19:11:55 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:57 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:57 freddy vdr: [3108] switching to channel 3 Sep 8 19:11:57 freddy vdr: [3410] transfer thread ended (pid=3108, tid=3410) Sep 8 19:11:57 freddy vdr: [3108] buffer stats: 141752 (6%) used Sep 8 19:11:57 freddy vdr: [3411] receiver on device 10 thread ended (pid=3108, tid=3411) Sep 8 19:11:58 freddy vdr: [3414] transfer thread started (pid=3108, tid=3414) Sep 8 19:11:58 freddy vdr: [3415] receiver on device 10 thread started (pid=3108, tid=3415) Sep 8 19:11:58 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:58 freddy vdr: [3414] setting audio track to 1 (0) Sep 8 19:12:01 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:12:03 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Digital. 9 audio working. Change to 8, working. Change to 9 audio not working Sep 8 19:06:35 freddy vdr: [3108] switching to channel 9 Sep 8 19:06:35 freddy vdr: [3108] cTS2PES got 0 TS errors, 2 TS continuity errors Sep 8 19:06:35 freddy vdr: [3108] cTS2PES got 0 TS errors, 1 TS continuity errors Sep 8 19:06:35 freddy vdr: [3108] buffer stats: 58280 (2%) used Sep 8 19:06:35 freddy vdr: [3336] transfer thread started (pid=3108, tid=3336) Sep 8 19:06:35 freddy vdr: [3334] TS buffer on device 1 thread ended (pid=3108, tid=3334) Sep 8 19:06:35 freddy vdr: [] buffer stats: 58656 (2%) used Sep 8 19:06:35 freddy vdr: [] receiver on device 1 thread ended (pid=3108, tid=) Sep 8 19:06:35 freddy vdr: [3337] receiver on device 1 thread started (pid=3108, tid=3337) Sep 8 19:06:35 freddy vdr: [3338] TS buffer on device 1 thread started (pid=3108, tid=3338) Sep 8 19:06:37 freddy vdr: [3336] setting audio track to 1 (0) Sep 8 19:07:57 freddy vdr: [3336] transfer thread ended (pid=3108, tid=3336) Sep 8 19:07:57 freddy vdr: [3108] switching to channel 8 Sep 8 19:07:57 freddy vdr: [3108] buffer stats: 95692 (4%) used Sep 8 19:07:57 freddy vdr: [3344] transfer thread started (pid=3108, tid=3344) Sep 8 19:07:57 freddy vdr: [3338] TS buffer on device 1 thread ended (pid=3108, tid=3338) Sep 8 19:07:57 freddy vdr: [3337] buffer stats: 95316 (4%) used Sep 8 19:07:57 freddy vdr: [3337] receiver on device 1 thread ended (pid=3108, tid=3337) Sep 8 19:07:57 freddy vdr: [3345] receiver on device 1 thread started (pid=3108, tid=3345) Sep 8 19:07:57 freddy vdr: [3346] TS buffer on device 1 thread started (pid=3108, tid=3346) Sep 8 19:07:58 freddy vdr: [3344] setting audio track to 1 (0) Sep 8 19:08:02 freddy vdr: [3344] transfer thread ended (pid=3108, tid=3344) Sep 8 19:08:03 freddy vdr: [3108] switching to channel 9 Sep 8 19:08:03 freddy vdr: [3108] buffer stats: 62792 (2%) used Sep 8 19:08:03 freddy vdr: [3349] transfer thread started (pid=3108, tid=3349) Sep 8 19:08:03 freddy vdr: [3346] TS buffer on device 1 thread ended (pid=3108, tid=3346) Sep 8 19:08:03 freddy vdr: [3345] buffer stats: 62416 (2%) used Sep 8 19:08:03 freddy vdr: [3345] receiver on device 1 thread ended (pid=3108, tid=3345) Sep 8 19:08:03 freddy vdr: [3350] receiver on device 1 thread started (pid=3108, tid=3350) Sep 8 19:08:03 freddy vdr: [3351] TS buffer on device 1
[vdr] [PATCH] vga-sync-fields 0.0.8
A new version of the patch 'vga-sync-fields-0.0.8.tgz' now is available at: http://lowbyte.de/vga-sync-fields History since last version announced here: 2008-09-08: Version 0.0.8 - enhanced a standalone tool for testing the Soft-PLL without xine-lib and Xserver - a fix in xineliboutput configuration (see README) greatly improved responsiveness of Soft-PLL to channel switches - implemented a workaround for sporadically lost interrupts on Radeon type hardware - added experimental DRM and tools support for i810. I just started the port from Radeon to i810. It's not yet documented and far from complete 2008-08-23: Version 0.0.7 - added a small patch for recent hg xine-lib (1.1.16) from 2008-08-20. Together with the patch the actual xine-lib gives good results for playback and live-TV. 2008-08-21: Version 0.0.6 - fixed a bug that erroneously could trigger recovery actions as if stray updates would have been occurred - since 40ms enhancement (see below) issues with DVB budget cards are considered as fixed. You now also can watch live-TV with the patch. But the time to switch a channel still should be optimized. It sometimes takes too long for the Soft-PLL to lock. 2008-08-19: Version 0.0.5 - frame rate now adapted every 1/25 second instead of only once per second as before. This should make rate adaptions invisible even if they change by large values - implemented a simple graphic which should give you a better overview of how regularly frame updates are issued from your decoder. And how the Soft-PLL copes with these updates - automatic sync of initial field polarity now has been removed. It's now part of 40ms double buffer update improvement (see vers. 0.0.4) - simplified/changed interface to DRM-module - adapted all tools to new interface have fun! Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Build plugin with different headers then in VDR distribution
Hi Michael On Monday, 8. September 2008 Michael Stepanov wrote: Thanks a lot, Dieter, for your solution. It seems very useful. Especially when VDR installed from the package and not from the sources. But I don't understand clearly how to run your script? What parameters should be passed there? Just keyword plugins? And where in should be run? From the building pluguns directory? I just have somewhere in my $HOME the live sources directory. I just cd into it and execute 'make-live' (the name of the previously posted script in my ~/bin). That will create the 'default' target of the live plugins Makefile which is the binary. You can execute 'make-live clean' to clean the sources from build artefacts. What you pass to the script is what you would pass to the normal make call. That way I build only the live plugin. The sources of the live plugin are *not* in the PLUGINS/src/live subdirectory like it would be with 'normal' VDR plugin development. A side note: the same Makefile (inside the live sources, without any modifications) is also suitable to build the LIVE plugin inside the VDRs PLUGIN directory. Hope this helps :) Kind regards Dieter Hametner -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Build plugin with different headers then in VDR distribution
Thanks a lot, Dieter, for your solution. It seems very useful. Especially when VDR installed from the package and not from the sources. But I don't understand clearly how to run your script? What parameters should be passed there? Just keyword plugins? And where in should be run? From the building pluguns directory? On Mon, Sep 8, 2008 at 1:57 PM, Dieter Hametner [EMAIL PROTECTED][EMAIL PROTECTED] wrote: Hello I started my contribution to the development of the LIVE plugin without installed vdr sources. I installed the vdr-dev package from e-tobi debian repository and used the following script to build the binary of the plugin. 'libvdr-live.so.1.6.0' is created in the .libs subdirectory then. Of course the binary had to be copied into the right installation path afterwards. #!/bin/sh # check if this are live sources # (there is an extra live subdir in the sources) [ -d live ] || exit 0 mkdir -p .libs VDRDIR=/usr/include/vdr LIBDIR=.libs make $* Kind regards Dieter Hametner -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Cheers, Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-webvideo 0.0.5
New version of the Webvideo plugin is available at http://users.tkk.fi/~aajanki/vdr/webvideo/vdr-webvideo-0.0.3.tgz The Webvideo plugin allows downloading video files from video sharing websites YouTube, Google Video, and YLE Areena to your hard disk using the VDR menu interface. This plugin only downloads videos. A separate plugin, such as xineliboutput or mplayer plugin, is required to play them. Changes since the last version announced on this list: 2008-08-21: Version 0.0.4 - Updated Italian translation (thanks to Diego Pierotto) - Include a workaround for a bug in the libmms header file mmsx.h which caused the compilation to fail - Fix compiler warnings 2008-09-08: Version 0.0.5 - New video service: SVT Play. Contributed by Lars Olsson. - More robust parsing of .asx files - Workaround for buggy servers: if the server reports the Content-Type of a video file as text/plain do not use it for deciding the file extension. Try to extract the extension from the URL instead. - Sort service names alphabetically -- Antti Ajanki ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fw: Problem with some HD-channels.
I have now uploaded ~20MB of data on: http://www.mellander.org/per/SD-Upscale-HD-SVT1.vdr This is ( I think ) an upscaled SD broadcast on the SVT HD channel. It behaves the same as an true HD broadcast on this channel. I will try to get some real HD material later tonight. /Per Goga777 skrev: I was running vdr-1.5.12 for quite som time, patched and with multiprotodrivers + CoreAVC I was able to watch HD channels on Thor 1.0W. The thing was that when I tried to watch: SVT HD;Telenor:11421:hC34M5S1Z35:S1.0W:25000:10512+512:640=sve;641=sve:0:B00:3801:70:14:0 I had problem with stuttering video and glitches in sound. The sound glitches came every second and the video was a little bit more stochastic in it's behaviour. I really wanted to be able to watch this channel because it's one of the 'official' swedish channels ( i.e Government owned ). I thought it was because of lack of CPU-power, so I bought an eHD and installed vdr 1.7.0. Everything was smooth as silk and I could watch almost all HD-channels without any problem. No more underpowered CPU glitches or crashes. Except for the SVT-channel that still had the problems noted above. :( So my question is, can anyone please tell me what special kind of stream that SVT is using and what I can do with my installation to be able to watch it? It's not FTA, but maybe someone could figure it out anyway. I can upload a short recording if anybody want to take a look. If you will record and will playback after that on vdr - will you have these problems ? Yes, please upload somewhere the 5-10 MB sample with this record, I will see Goga ___ 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] Fw: about eHD from Reelmultimedia (was - VDR Development)
Dear Georg could you clarify the delivery price of eHD to Russia, please Currently the delivery of eHD to Russia is 250 euro. It's stupid !!! Goga On Mon, Sep 08, 2008 at 12:09:11AM +0400, Goga777 wrote: Yes right that might be an option for short time. Micronas stopped the support of the used chips I think. Support!=availability How many boards can be equipped with the available chips AFAIK we have received no last order date yet. I don't know of any sourcing problems. How many boards are available for vdr users? Enough... ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] fedora 9 vdr-1.6.0 - int no audio on channel change
The more I test this, it looks like a vdr-xine problem. Recordings have audio, and the live channel has audio if I restart xine. Can anyone suggest what I can try?? I should probably also note, I'm running vdr-xine and the audio returns if I kill xine and restart. Thanks Hi I've built a new fedora 9 x86_64 system (twice!) and get an intermittant problem when changing channels - no audio!! I've tried it with pvrinput analog channels, as well as digital channels via my TT-1501, TT-2300 (both with CAMs). When I change to a neighbouring channel and back again, I often get audio. Weird huh? Here's the /var/log/messages from the experience. Any ideas?? What can I try - seems like something is resetting and the audio starting with pvrinput, and nothing resetting with the TT-1501 card. HELP!!! This has been going on for months. pvrinput. 2 audio works. Change to 3, audio doesn't work. Then after 4 seconds works on it's own Sep 8 19:11:53 freddy vdr: [3108] switching to channel 2 Sep 8 19:11:53 freddy vdr: [3406] transfer thread ended (pid=3108, tid=3406) Sep 8 19:11:53 freddy vdr: [3108] buffer stats: 141000 (6%) used Sep 8 19:11:53 freddy vdr: [3407] receiver on device 10 thread ended (pid=3108, tid=3407) Sep 8 19:11:53 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:54 freddy vdr: [3410] transfer thread started (pid=3108, tid=3410) Sep 8 19:11:54 freddy vdr: [3411] receiver on device 10 thread started (pid=3108, tid=3411) Sep 8 19:11:55 freddy vdr: [3410] setting audio track to 1 (0) Sep 8 19:11:55 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:57 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:57 freddy vdr: [3108] switching to channel 3 Sep 8 19:11:57 freddy vdr: [3410] transfer thread ended (pid=3108, tid=3410) Sep 8 19:11:57 freddy vdr: [3108] buffer stats: 141752 (6%) used Sep 8 19:11:57 freddy vdr: [3411] receiver on device 10 thread ended (pid=3108, tid=3411) Sep 8 19:11:58 freddy vdr: [3414] transfer thread started (pid=3108, tid=3414) Sep 8 19:11:58 freddy vdr: [3415] receiver on device 10 thread started (pid=3108, tid=3415) Sep 8 19:11:58 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:11:58 freddy vdr: [3414] setting audio track to 1 (0) Sep 8 19:12:01 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Sep 8 19:12:03 freddy kernel: saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Digital. 9 audio working. Change to 8, working. Change to 9 audio not working Sep 8 19:06:35 freddy vdr: [3108] switching to channel 9 Sep 8 19:06:35 freddy vdr: [3108] cTS2PES got 0 TS errors, 2 TS continuity errors Sep 8 19:06:35 freddy vdr: [3108] cTS2PES got 0 TS errors, 1 TS continuity errors Sep 8 19:06:35 freddy vdr: [3108] buffer stats: 58280 (2%) used Sep 8 19:06:35 freddy vdr: [3336] transfer thread started (pid=3108, tid=3336) Sep 8 19:06:35 freddy vdr: [3334] TS buffer on device 1 thread ended (pid=3108, tid=3334) Sep 8 19:06:35 freddy vdr: [] buffer stats: 58656 (2%) used Sep 8 19:06:35 freddy vdr: [] receiver on device 1 thread ended (pid=3108, tid=) Sep 8 19:06:35 freddy vdr: [3337] receiver on device 1 thread started (pid=3108, tid=3337) Sep 8 19:06:35 freddy vdr: [3338] TS buffer on device 1 thread started (pid=3108, tid=3338) Sep 8 19:06:37 freddy vdr: [3336] setting audio track to 1 (0) Sep 8 19:07:57 freddy vdr: [3336] transfer thread ended (pid=3108, tid=3336) Sep 8 19:07:57 freddy vdr: [3108] switching to channel 8 Sep 8 19:07:57 freddy vdr: [3108] buffer stats: 95692 (4%) used Sep 8 19:07:57 freddy vdr: [3344] transfer thread started (pid=3108, tid=3344) Sep 8 19:07:57 freddy vdr: [3338] TS buffer on device 1 thread ended (pid=3108, tid=3338) Sep 8 19:07:57 freddy vdr: [3337] buffer stats: 95316 (4%) used Sep 8 19:07:57 freddy vdr: [3337] receiver on device 1 thread ended (pid=3108, tid=3337) Sep 8 19:07:57 freddy vdr: [3345] receiver on device 1 thread started (pid=3108, tid=3345) Sep 8 19:07:57 freddy vdr: [3346] TS buffer on device 1 thread started (pid=3108, tid=3346) Sep 8 19:07:58 freddy vdr: [3344] setting audio track to 1 (0) Sep 8 19:08:02 freddy vdr: [3344] transfer thread ended (pid=3108, tid=3344) Sep 8 19:08:03 freddy vdr: [3108] switching to channel 9 Sep 8 19:08:03 freddy vdr: [3108] buffer stats: 62792 (2%) used Sep 8 19:08:03 freddy vdr: [3349] transfer thread started (pid=3108, tid=3349) Sep 8 19:08:03 freddy vdr: [3346] TS buffer on device 1 thread ended (pid=3108, tid=3346) Sep 8 19:08:03 freddy vdr: [3345] buffer stats: 62416 (2%) used Sep 8 19:08:03 freddy vdr: [3345] receiver on device 1 thread ended
Re: [vdr] VDR Development
Klaus Schmidinger wrote: On 09/07/08 19:42, Clemens Kirchgatterer wrote: ... i always wondered why dvb support was directly compiled in while other back and frontends were supposed to be plugins. this clearly leaves a sign that dvb is the preferd plattform. Well, it was the first one - long before there even was a plugin interface. Maybe this is worth another thought: In times of DVBAPI, Multiproto and S2API, a separated DVB plugin could easily be split into three flavors. And a core VDR that is no longer dependent on Linux kernel interfaces would be a lot more portable too. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] some problem with hdtv channels from Eurobird 9E
Hi there's several open hdtv channels on Eurobird 9e MelodyZen.tv;EUTELSAT:11804:VO0S0:S9.0E:27500:3321:3322=NAT,3323=MUS,3324=eng,3326=fra:0:0:332:158:158:0 LUXE.TV HD;DVL.TV:11804:VO0S0:S9.0E:27500:3011:3013=fra,3014=eng,3015=deu,3016=ita,3017=rus,3018=esl:0:0:301:158:158:0 LUXE.TV UK HD;DVL.TV:11804:VO0S0:S9.0E:27500:3041:3044=eng;3043=eng:0:0:304:158:158:0 but with each channels I have the problem on my vdr 170 + xineliboutput + svn ffmpeg On MelodyZen I have jerking pictures with slow motion in the log I have 200 frames delivered, 78 frames skipped, 0 frames discarded video_out: throwing away image with pts 10711859 because it's too old (diff : 4105). 200 frames delivered, 75 frames skipped, 1 frames discarded 200 frames delivered, 80 frames skipped, 0 frames discarded 200 frames delivered, 81 frames skipped, 0 frames discarded 200 frames delivered, 79 frames skipped, 0 frames discarded 200 frames delivered, 79 frames skipped, 0 frames discarded I tried to record this channels and playback again by vdr - I have the same problem. But if I will try to play this file by ffplay - I don't this problem - the video is smoothly. It's seems there's problem with xineliboutput or xine-lib-1.2 the other hdtv channels LUXE.TV HD;DVL.TV:11804:VO0S0:S9.0E:27500:3011:3013=fra,3014=eng,3015=deu,3016=ita,3017=rus,3018=esl:0:0:301:158:158:0 LUXE.TV UK HD;DVL.TV:11804:VO0S0:S9.0E:27500:3041:3044=eng;3043=eng:0:0:304:158:158:0 have the problem as well. BUT with szap2 ffplay I can see this channels without any problem ./szap2 -c 9 -n4 -r -p cat /dev/dvb/adapter0/dvr0 | ffplay - could someone test these hdtv channels Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR git tree (was: Re: VDR Development)
Hello This is an spin off from the VDR Development thread. On Sunday, 7. September 2008 Clemens Kirchgatterer wrote: Georg Acher [EMAIL PROTECTED] wrote: I also don't think that a vdr-repository would help in the development speed. Either the whole development procedure needs to be changed (more maintainer with KLS's approval) or it has no advantage compared to the .tgz-distribution. maybe using git, where you can pull into your own repository for privat vdr hacking and let other people check it out may be worth a thought. I've had this idea since the beginning of this year. But now I thought I give it a try. I present a VDR git at http://vdr.gekrumbel.de/git/?p=vdr.git First of all: This is not meant to be a fork of VDR development. Please read my explanation why it can't be: Git is a distributed source code management system. That means every git working tree contains the full history of the whole project plus the history added by the owner of a tree. The tree I present here is *read* *only* for the whole world. That means Michael Brückner or I will update it some time after Klaus releases a new VDR version or patch to the stable sources. Only code from Klaus will be committed into this tree. That means it is a exact copy of Klaus sources and the history of official VDR development. And it never will be more! Other developers will benefit from this work by having a base from where they can clone their own trees, add their contributions and publish their work as git trees too. They are strongly encouraged to make clear what distinguishes their trees from the original vanilla VDR. Whenever Klaus releases new code, they can merge the changes by pulling from this VDR tree. When we learn about such clones we will add them into a list of contribution work. Please let me (us) know when such a tree comes alive. Eventually somebody will take all the distributed contributions and merge them into one big all contributions tree. I am convinced that this approach gives Klaus the freedom to add features to VDR in the way he thinks is most appropriate for the overall stability and quality of his code. On the other side, using the distributed and collaborative approach, which is well supported by using git, gives the community the possibility to add enhancements to VDR and have a chance to make these changes trackable (no longer the need for everybody interested to go through the patch search hell). In essence this is an approach on better manageing the various patch sets floating around. This can only be successful if the most active VDR contributors adopt this approach and start working towards this goal. And it will need a lot of discipline of everybody involved. To contact Michael and myself you should use the email address: [EMAIL PROTECTED] Kind regards Dieter Hametner -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with some HD-channels. (xine-lib or xineliboutput ???)
Приветствую, Per thanks for your sample http://www.mellander.org/per/SD-Upscale-HD-SVT1-10mb.vdr I tried to play it by ffplay/xine - everything is ok but vdr 170 + xineliboutput couldn't play correctly it due to some errors [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one skip [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]non-existing PPS referenced [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]mmco: unref short failure [h264 @ 0x8484170]mmco: unref short failure [h264 @ 0x8484170]non-existing PPS referenced [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]mmco: unref short failure [h264 @ 0x8484170]mmco: unref short failure [h264 @ 0x8484170]non-existing PPS referenced [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]mmco: unref short failure [h264 @ 0x8484170]mmco: unref short failure [h264 @ 0x8484170]non-existing PPS referenced [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]mmco: unref short failure [h264 @ 0x8484170]mmco: unref short failure skip [h264 @ 0x8484170]non-existing PPS referenced [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]non-existing PPS referenced [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]non-existing PPS referenced [h264 @ 0x8484170]decode_slice_header error [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]number of reference frames exceeds max (probably corrupt input), discarding one [h264 @ 0x8484170]mmco: unref short failure Ошибка сегментирования I think there is some problem with xine-lib-1.2 or xineliboutput Goga I was running vdr-1.5.12 for quite som time, patched and with multiprotodrivers + CoreAVC I was able to watch HD channels on Thor 1.0W. The thing was that when I tried to watch: SVT HD;Telenor:11421:hC34M5S1Z35:S1.0W:25000:10512+512:640=sve;641=sve:0:B00:3801:70:14:0 I had problem with stuttering video and glitches in sound. The sound glitches came every second and the video was a little bit more stochastic in it's behaviour. I really wanted to be able to watch this channel because it's one of the 'official' swedish channels ( i.e Government owned ). I thought it was because of lack of CPU-power, so I bought an eHD and installed vdr 1.7.0. Everything was smooth as silk and I could watch almost all HD-channels without any problem. No more underpowered CPU glitches or crashes. Except for the SVT-channel that still had the problems noted above. :( So my question is, can anyone please tell me what special kind of stream that SVT is using and what I can do with my installation to be able to watch it? It's not FTA, but maybe someone could figure it out anyway. I can upload a short recording if anybody want to take a look. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR git tree (was: Re: VDR Development)
It had taken a lot of time to commit all versions of vdr into the git repository, I would think. Thank you for the great work! This will be the first big step in distributed patch and plugin development for the great vdr project. Servus Christian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] some problem with hdtv channels from Eurobird 9E
On Monday 08 of September 2008, Goga777 wrote: Hi there's several open hdtv channels on Eurobird 9e MelodyZen.tv;EUTELSAT:11804:VO0S0:S9.0E:27500:3321:3322=NAT,3323=MUS,3324=e ng,3326=fra:0:0:332:158:158:0 LUXE.TV HD;DVL.TV:11804:VO0S0:S9.0E:27500:3011:3013=fra,3014=eng,3015=deu,3016=ita, 3017=rus,3018=esl:0:0:301:158:158:0 LUXE.TV UK HD;DVL.TV:11804:VO0S0:S9.0E:27500:3041:3044=eng;3043=eng:0:0:304:158:158:0 but with each channels I have the problem on my vdr 170 + xineliboutput + svn ffmpeg On MelodyZen I have jerking pictures with slow motion in the log I have 200 frames delivered, 78 frames skipped, 0 frames discarded video_out: throwing away image with pts 10711859 because it's too old (diff : 4105). 200 frames delivered, 75 frames skipped, 1 frames discarded 200 frames delivered, 80 frames skipped, 0 frames discarded 200 frames delivered, 81 frames skipped, 0 frames discarded 200 frames delivered, 79 frames skipped, 0 frames discarded 200 frames delivered, 79 frames skipped, 0 frames discarded I tried to record this channels and playback again by vdr - I have the same problem. But if I will try to play this file by ffplay - I don't this problem - the video is smoothly. It's seems there's problem with xineliboutput or xine-lib-1.2 the other hdtv channels LUXE.TV HD;DVL.TV:11804:VO0S0:S9.0E:27500:3011:3013=fra,3014=eng,3015=deu,3016=ita, 3017=rus,3018=esl:0:0:301:158:158:0 LUXE.TV UK HD;DVL.TV:11804:VO0S0:S9.0E:27500:3041:3044=eng;3043=eng:0:0:304:158:158:0 have the problem as well. BUT with szap2 ffplay I can see this channels without any problem ./szap2 -c 9 -n4 -r -p cat /dev/dvb/adapter0/dvr0 | ffplay - could someone test these hdtv channels Goga Hi, no problem here with vdr-1.7.0 + h.264 patch +eHD MelodyZen.tv;EUTELSAT:11804:vC34M2O0S0:S9.0E:27500:3321:3322=NAT,3323=MUS,3324=eng,3326=fra:0:0:332:158:158:0 LUXE.TV HD;DVL.TV:11804:vC34M2O0S0:S9.0E:27500:3011:3013=fra,3014=eng,3015=deu,3016=ita,3017=rus,3018=esl:0:0:301:158:158:0 LUXE.TV UK HD;DVL.TV:11804:vC34M2O0S0:S9.0E:27500:3041:3044=eng;3043=eng:0:0:304:158:158:0 BR, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
