Re: [vdr] VDR not cleaning .del directories
Klaus Schmidinger kirjoitti 17.01.2018 klo 11:59: On 16.01.2018 19:44, Teemu Suikki wrote: Hi, I just experienced weird problem. My hard drive became 100% full. ... This is somehow related to the fact that I now have Plex Media Server sitting on the VDR recordings directory. But still I could remove the .del directories easily from the command line. After manually deleting them, disk is now only 85% full.. And that's 4TB drive. :) So there were quite a bit of .del directories. Do you have anything going on that causes frequent "user ineraction" with VDR? I had a similar problem some time ago (I don't remember how many years, but with vdr 2.2.0). I reported on this mailing list then, but I did not find that email with a short search, now. My video directory is nfs-mounted to a raspberry pi running another vdr. In my case, I have not changed the configuration in any way, but despite of daily usage, this has not reoccurred. So either some other patch fixed the problem for me, or this is some extremely rarely happening race condition type thing. yours, Jouni ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] NOW SOLVED!!! buffer overruns and sync probs after change of receivers
17.02.2016, 23:14, Harald Milz kirjoitti: Question: has anyone successfully run vdr-2.0.3 or -2.2.0 with the 4.2.0 kernel using a PCIe card? And while we're at it, a PCIe USB3 card with a harddisk attached? It seems that some kernel buffer starts choking after, like, 150 or more GB have been transferred. If that is a common problem (on any Ubuntu distro running the wily HWE kernel or on 15.10 itself) it should be mentioned somewhere - no idea where. vdr-wiki.de maybe. I am running Ubuntu 15.10, uname -a Linux xpc 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux dpkg -l ii vdr 2.0.6-2amd64Video Disk Recorder for DVB cards PCIe DVBSky T982 and T980C cards (cable), total 5 adapters I don't have this problem. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] rpi + server removed almost all recordings
hi, I have a Raspberry Pi frontend (vdr 2.2.0) with a server (vdr 2.0.6 from yavdr). Last night the disk was full, and vdr started to remove old recordings. For some reason, they did not remove just enough to fit in the new recordings, but cleared about 2TB of old recordings. Earlier, (with a self-compiled 2.2.0 server side) vdr only cleared just enough to fit the new recordings. The removing messages appear on the raspberry side. As it is not the one recording, I think it would be logical if the vdr instance that is actually recording would also do the cleanup. I wonder if there is a way to prevent it from removing recordings? I did not find a setup option for that. Or is the problem somewhere else? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + rpihddevice + skinnopacity
hi, 01.04.2015, 22:47, Thomas Reufer kirjoitti: There was a bug in git which is now fixed. Sorry for the inconvenience! But in general, this could happen if there's not enough GPU memory available, so the skin should check for a valid pixmap. For the next developer version of vdr, It also needs to query the maximal possible dimension prior creation, otherwise rpihddevice will then just return NULL if an oversized pixmap is requested. Regards, Thomas Now the accelerated OSD seems to work. Thank you for your work! I am astonished about this small computer and the capabilities. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr + rpihddevice + skinnopacity
hi, I have the following problem: when pressing menu with my Raspberry pi Lirc, VDR crashes: Mar 31 13:51:09 vdrfe vdr: [2456] rpihddevice: [OpenVG] cannot allocate pixmap of 2804px x 781px, clipped to 2048px x 781px! Mar 31 13:51:09 vdrfe vdr: [2469] rpihddevice: [EGL] failed to create pixel buffer surface: bad alloc! Mar 31 13:51:09 vdrfe vdr: [2456] rpihddevice: [OpenVG] failed to create pixmap! (allocation failed) setup: - vdr 2.2.0 - raspberry pi current git - skinnopacity 1.1.3 + the second version of skinnopacity remotetimers patch - remotetimers v 1.0.1 I have set gpu_mem to 256M With rpihddevice from git Mar 8th, no crashes, but I could not use accelerated OSD (the subtitles did not work). I pulled the repository again about a week ago, and got accelerated osd working. Yesterday the problem I described started, and I re-pulled the git, because it seemed there was a fix. Not working. When not using accelerated OSD, it works fine, but rendering subtitles takes so long that there is hardly time to read them. Any suggestions? Should I insert more debug info? (what and how?) yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Fwd: Re: raspbian apt repo with up to date vdr packages?
On 09.03.2015 16:31, VDR User wrote: Have you tried compiling the sources yourself? It'll probably take a while but as long as no voodoo/magic is required, I don't see why not. I am in the process. Using the instructions from http://www.vdr-wiki.de/wiki/index.php/Kategorie:Raspbian_VDR_Streaming_Client_mittels_Streamdev_und_rpihddevice It seems that concerning streamdev patches: not needed for streamdev. And one hunk needs to be manually applied for remotetimers for 2.2.0 For some reason; skinnopacity + remotetimers seems to cause the menus flash in and out. Tried the latest tarball. Now trying the git. I hope it works; I prefer the default skinnopacity over lcars. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with subtitles: not showing in HD channels
vdr 2.1.6 (self-compiled) with vdr-xine-0.9.4 plugin and debians packaged libxine2 shows YLE HD subtitles fine. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] locale problem with 1.7.41
17.03.2013 12:37, Klaus Schmidinger kirjoitti: On 17.03.2013 10:57, Halim Sahin wrote: Hi, I see locale problems as well. I've used LCLBLD and no locales were installed in ./locale after make run. I typed make i18n which helped. I just verified that a plain 'make' does generate the ./locale directory with all locales when using LCLBLD. hi, thanks for the answer - I got it working. It was my confusion in building the program with the new LCLBLD and ONEDIR options. Unfortunately I have no idea on how to improve the instructions on the INSTALL file to avoid such confusion for others. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] half-viewed recordings, can they be moved at the top of the list?
an additional problem is the definition of viewed. I don't normally view the end credits. Also, I have normally 10min extra in the end of each recording, just in case. So normally there are around 10-15mins in the end of a viewed recording that have not been viewed. But this would probably vary - a little different for each user. Seems a difficult thing to do right. Matti's plugin sounds like a working solution, instead. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] in-kernel lirc and devinput
On 20.10.2012 15:18, Tony Houghton wrote: Strange. FWIW I used to use the Hauppauge grey remote, but I replaced that card and none of my other receivers came with suitable remotes (not enough buttons etc) so I bought an HP MCE remote and cheap generic MCE receiver With a bit of fiddling and a reboot and both mouse and keyboard codes are nicely received by inputlirc. For me, the benefit of in-kernel drivers and inputlirc is that there is again fewer non-packetized components in the system, so updates are again easier. For some reason, there were a couple of non-functioning buttons with lirc, and now with rc-keymaps and inputlirc some non-functioning again, but they are different keys. I wonder if there is a mailing list for these things; I could report the keys there. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] in-kernel lirc and devinput
Thanks for the suggestions. On 18.10.2012 00:05, Tony Houghton wrote: I prefer inputlirc to the original lirc. If you configure it to start at boot and grab the input device it should stop X or whatever from interpreting it as key presses. It seems easy, but when I moved to inputlirc, now I have the number keys but not the menu key and a few other keys. They come on a separate event interface. I disabled both in hal and in Xorg both these iMON things, but it did not help. The inputlirc config: # Options to be passed to inputlirc. EVENTS=/dev/input/by-id/usb-15c2_0036-event* OPTIONS=-g -c -m 0 -d/dev/lircd yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] in-kernel lirc and devinput
hi, earlier, I used to compile lirc separately, but nowadays there are lirc modules in the kernel source, using /dev/input and IR keymaps. After switching to these, it seems many of the buttons in the remote have stopped working, as they are now interpreted as keyboard presses instead of RC commands for lirc. Is there a howto-guide somewhere on how to set up VDR when using the new in-kernel features? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
On 12.08.2012 12:23, Klaus Schmidinger wrote: But is it really that necessary? It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me). yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Make RGYB buttons customizable (attempt 2)
On 12.08.2012 15:46, JJussi wrote: On 12.8.2012 15.32, Klaus Schmidinger wrote: On 12.08.2012 14:28, Jouni Karvo wrote: On 12.08.2012 12:23, Klaus Schmidinger wrote: But is it really that necessary? It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me). Do you actually *have* a remote control with non-standard color keys? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I have too.. Already for years (from 2005).. I have RGBY. It's Silver Stone -case with integrated IR remote. Me too. RGBY yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] HDMI output detection problems
hi, since starting to use a AV receiver between TV and VDR, I have had HDMI detection problems. To start X server even when TV is not on, I use custom edid file that I got from the tuner. With this, VDR always starts X properly, so even if VDR has auto-started for recording, the output works. Card: Nvidia GT220, vdr-xine plugin, Xorg, NAD receiver and Sony TV. If I start TV, though, for some reason, most often there is no negoatiation (or a failed one) between the receiver and VDR, so there will be no picture. Normally there is a sound, though. I have to switch the input selector of the receiver first to DVD input, then back to TV input to get the image. If the tuner and TV are on when X server starts, the image appears correctly. Are there any flags in nvidia-settings or Xorg.conf or Xine configuration that would tell the graphics card to help the tuner to notice that there indeed is an image also on the HDMI cable? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDMI output detection problems
On 28.07.2012 18:14, VDR User wrote: HDMI in. That's all. How is your setup cabled? I've heard a similar story before and it turned out to be a quirky receiver but I can't say if NAD has that problem or not. VDR-(HDMI)-Receiver-(HDMI)-TV yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Xine plugin and vdr 1.7.27
hi, it seems xine-plugin 0.9.4 does not compile with vdr 1.7.27. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.23 uses the wrong DVB headers
On 15.01.2012 22:46, Udo Richter wrote: Hi list, And here I was, thinking that I could finally drop support for this old compatibility patch that noone really needs any more, and then the new VDR-1.7.23 requires linux-3.0 or newer headers to compile... yay... Hi, I have a self compiled 3.2.1-SMP kernel in Debian: fakeroot make-kpkg --initrd --append-to-version=-jk kernel-image kernel-headers and installed both packages. For some reason, the file /usr/include/linux has DVBversion major 5 minor 1. The kernel headers are in the /usr/src/linux-headers-($shell uname -r) directory. I tried to use this in the DVBDIR variable in Make.config, as adviced in the INSTALL-file but with no success. It did not seem to have any effect. So - what to do? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.23 uses the wrong DVB headers
On 16.01.2012 20:47, Jouni Karvo wrote: Hi, I have a self compiled 3.2.1-SMP kernel in Debian: Never mind - I found the instructions in the HISTORY file. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine with new AAC LATM support
On 13.09.2011 14:16, Chris Rankin wrote: Hi, Just in case anyone is interested: There has been a sudden spike in xine development (1.1.19 branch), and AAC LATM audio should now be working with MPEG-TS streams. You will also need to be using FFmpeg = 0.7. Where can that be found? The repositories at xine-project.org - alioth mercurial are from Apr 2008. At least xine-lib-1.2 was. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.4 plugin
On 18.03.2011 21:18, Jouni Karvo wrote: On 17.03.2011 18:21, Jouni Karvo wrote: Thanks for the update. Seems so far to work nicely. The INSTALL file points to the jusst.de tree, but I thought that the libxine-1.2 is now at the xine-project mercurial (where, it seems, are some changes by you :) This vdr-xine, combined with libxine-1.2 from xine-project mercurial (current) and nvidia driver x86_64-260.19.36 produces segfaults for xine pretty often (every 15min to 1h, both viewing recordings and live TV). Here a backtrace of one of them. ... never mind - it seems that my xine-ui was too old for the new xine-lib-1.2. The same seems to have caused the vdr startup problems I experienced. your, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.4 plugin
On 17.03.2011 18:21, Jouni Karvo wrote: Thanks for the update. Seems so far to work nicely. The INSTALL file points to the jusst.de tree, but I thought that the libxine-1.2 is now at the xine-project mercurial (where, it seems, are some changes by you :) This vdr-xine, combined with libxine-1.2 from xine-project mercurial (current) and nvidia driver x86_64-260.19.36 produces segfaults for xine pretty often (every 15min to 1h, both viewing recordings and live TV). Here a backtrace of one of them. Program terminated with signal 6, Aborted. #0 0x7f165ca0f165 in raise () from /lib/libc.so.6 (gdb) bt #0 0x7f165ca0f165 in raise () from /lib/libc.so.6 #1 0x7f165ca11f70 in abort () from /lib/libc.so.6 #2 0x00492082 in xitk_signal_handler () #3 signal handler called #4 0x7f165ca4ff4f in ?? () from /lib/libc.so.6 #5 0x7f165ca5384c in free () from /lib/libc.so.6 #6 0x7f16454a4b0c in vdpau_mpeg12_decode_data (this_gen=0x1d2b790, buf=value optimized out) at vdpau_mpeg12.c:823 #7 0x7f165dd83a7b in video_decoder_loop (stream_gen=value optimized out) at video_decoder.c:382 #8 0x7f165cd448ba in start_thread () from /lib/libpthread.so.0 #9 0x7f165caac02d in clone () from /lib/libc.so.6 #10 0x in ?? () yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.4 plugin
On 17.03.2011 00:12, Reinhard Nissl wrote: Hi, Am 16.03.2011 20:29, schrieb Reinhard Nissl: - Added support for VDR-1.7.17s TrueColor OSD. I forgot to mention, that TrueColor OSD is currently only possible with VDPAU. Furthermore you have to select an OSD display mode different from X11 overlay in vdr-xines setup menu. Despite the name of this mode, it is currently not ARGB capable. Thanks for the update. Seems so far to work nicely. The INSTALL file points to the jusst.de tree, but I thought that the libxine-1.2 is now at the xine-project mercurial (where, it seems, are some changes by you :) yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] startup problems
On 16.02.2011 20:36, VDR User wrote: On Wed, Feb 16, 2011 at 6:48 AM, Jouni Karvojouni.ka...@iki.fi wrote: I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble? Check the VDR log and xine log. If VDR has a problem starting, you should be able to find out why in it's log. And if it's xine related, you then check the xine log.. And so on.. Just follow the crumbs until you find the problem. Shouldn't be too hard. :) That was done already: vdr -l 3, xine --verbose=2; there is no hint on syslog or console output - except this, on the main thread: Feb 17 16:48:57 vdr vdr: [3956] TS buffer on device 1 thread started (pid=3897, tid=3956) Feb 17 16:49:57 vdr vdr: [3897] PANIC: watchdog timer expired - exiting! and on another occasion: Feb 17 16:47:48 vdr vdr: [3852] cVideoRepacker: switching to MPEG1/2 mode Feb 17 16:47:48 vdr vdr: [3852] cVideoRepacker: operating in MPEG1/2 mode Feb 17 16:47:50 vdr vdr: [3820] EPGSearch: search timer update finished Feb 17 16:48:48 vdr vdr: [3794] PANIC: watchdog timer expired - exiting! I have tried to keep things simple and to use lirc from vdr, instead of from xine. I guess I have to start studying how to use the xine plugin as remote control. Ymph - I tried to set ulimit -c unlimited, but I cannot find the core for this, found in the log: Feb 17 16:48:48 vdr kernel: section handler[3799]: segfault at 61 ip 0046188d sp 7f59275fb4f0 error 4 in vdr-prod[40+13d000] (vdr-prod is the name of the production binary of vdr in my box) is this really a segfault inside the kernel? This segfault does not happen nearly all the watchdog-expiration cycles. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] startup problems
hi, after upgrading my kernel to 2.6.37 SMP PREEMPT x86_64 and switching to the in-kernel lirc devinput drivers, I have had vdr startup problems. At some boots; typically when the system wakes up from sleep, either by RTC or by power key from the remote, VDR watchdog-restarts every 1 minute for arond 10 times (this last time, it did it 14 times). Only after that it starts properly, xine starts and picture, sound and remote control start working. When rebooting, vdr might start immediately, without this restart hassle. Before; using the imon drivers, this problem did not occur. vdr-1.7.16, lircd from the git repo. I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
I don't understand what would be easy in using SQL. Since the channels.conf-code is already there, and pretty stable, then obviously rewriting that to SQL is not easy, but instead additional work. Justifying additional work needs some reason. I think adding dependencies to outside packages is a burden that should be avoided. There are already many things I need to install separately in order the vdr box to work; kernel, graphics drivers, and xine-lib. Luckily, lirc is now already part of the kernel, and DVB drivers, too; much less hassle than before. This is the right direction to go - not adding more moving parts that need to be installed (with compatible versions). yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.3.2
On 27.08.2010 20:44, Antti Ajanki wrote: New version of the Webvideo plugin is available at http://users.tkk.fi/~aajanki/vdr/webvideo/ Tried compiling with vdr 1.7.15. Does not work, because the vdr include directory is under include, not where the sources are. May I suggest adding a VDRINCLUDEDIR variable, and -I option, and removing the vdr/ from the #include statements in the future versions. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.3.2
On 11.09.2010 18:45, Rolf Ahrenberg wrote: On Sat, 11 Sep 2010, Antti Ajanki wrote: On 09/11/2010 01:44 PM, Jouni Karvo wrote: May I suggest adding a VDRINCLUDEDIR variable, and -I option, and removing the vdr/ from the #include statements in the future versions. Thanks for the suggestion. I will add variable for the include dir as you proposed. I'd rather suggest to use the VDR standard to compose the Makefile: VDRDIR = ../../.. ... -include $(VDRDIR)/Make.global -include $(VDRDIR)/Make.config ... INCLUDES += -I$(VDRDIR)/include I followed Rofa's suggestion, and this way it compiles nicely for 1.7.15 (and seems to work, too). Thanks! yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.3.1
On 04.08.2010 22:00, Antti Ajanki wrote: On 08/03/2010 11:58 AM, Jouni Karvo wrote: Hi; a feature request: - could you add a method for deleting the downloaded video files? I would find this most useful - having to take a ssh connection to the HTPC for deleting files is a bit cumbersome. Currently webvideo doesn't even keep track of which files it has downloaded. I think that the proper place to delete the videos is the media player. For example in xineliboutput's media player's file list the yellow key deletes a file. Ah. Anyone know how to delete a file with the mplayer plugin? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.3.1
On 25.07.2010 21:14, Antti Ajanki wrote: Hi, I just released version 0.3.1 of the webvideo plugin. The new version fixes (among other things) the incompability that was caused by Youtube recently changing their output format. Hi; a feature request: - could you add a method for deleting the downloaded video files? I would find this most useful - having to take a ssh connection to the HTPC for deleting files is a bit cumbersome. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xine - VDpau config help
On 15.06.2010 11:20, István Füley wrote: Glad to hear, that you managed to fix it. I don't think that the broadcaster will care about it :( How the GT220 is working with vdpau? Is the temporal_spatial deinterlacing working without freezes or dropped frames? I'm thinking about buying a similar card, at the moment I'm using a Geforce 8xxx onboard series, and it is not capable of temporal_spatial at full HD resolution. Or maybe I should wait for the TT FF DVB-S2... It is working fine. It seems it reports using temporal-spatial when deinterlacing SD (I have X configured to 1080p) and temporal (even if the config option asks for temporal-spatial) for HD. Seems to work nicely, and smoothly. Every (perhaps) 10-15 min there is some short problem, when it seems to get stuck to a point, repeating a second of video a few times, then continuing normally. But that could be a problem with xine (or some other option in xine config), too. I have a passively cooled version of the card. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xine - VDpau config help
On 12.06.2010 20:59, István Füley wrote: Jouni Karvo wrote: video.output.vdpau_honor_progressive:1 Try to change it back to 0. Ah. Seems you are right - the problem is in the broadcast. I sent an improvement suggestion, let's see whether they bother to respond. Thanks for the help! yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.14 + xine fails with h.264
Luca Olivetti kirjoitti: En/na Reinhard Nissl ha escrit: Since 1.7.12, VDR records PCR. Please apply the patch found in the below link to vdr-xine-0.9.3: http://www.linuxtv.org/pipermail/vdr/2010-February/022368.html It doesn't happen with all channels, though, I'm currently using an unpatched xine-0.9.3 (patching now) with vdr-1.7.14 and I can see bbchd with no problems. Bye This patch does help, thanks! yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.14 + xine fails with h.264
hi, since I updated from vdr-1.7.11, there is some change in the way H.264 is treated: With 1.7.11 + xine with vdpau support, I can watch H.264 HDTV shows without problems. Occasionally, there is a small glitch. But with 1.7.14 + the same version of xine, H.264 (both SDTV and HDTV) fail. Syslog reports: Mar 27 13:20:22 vdr vdr: [24138] receiver on device 1 thread started (pid=20841, tid=24138) Mar 27 13:20:22 vdr vdr: [24139] TS buffer on device 1 thread started (pid=20841, tid=24139) Mar 27 13:20:22 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:22 vdr vdr: [24138] SetBrokenLink: no GOP header found in video packet Mar 27 13:20:23 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:24 vdr vdr: [24138] SetBrokenLink: no GOP header found in video packet Mar 27 13:20:25 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:25 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:25 vdr vdr: [24138] SetBrokenLink: no GOP header found in video packet Mar 27 13:20:25 vdr vdr: [26422] femon receiver thread started (pid=20841, tid=26422) Mar 27 13:20:25 vdr vdr: [26524] femon osd thread started (pid=20841, tid=26524) Mar 27 13:20:25 vdr vdr: [24138] ERROR: 1 ring buffer overflow (45 bytes dropped) Mar 27 13:20:26 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:27 vdr vdr: [24138] SetBrokenLink: no GOP header found in video packet Mar 27 13:20:30 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:30 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:31 vdr vdr: [24138] SetBrokenLink: no GOP header found in video packet Mar 27 13:20:32 vdr vdr: [24138] cVideoRepacker: operating in H.264 mode Mar 27 13:20:32 vdr vdr: [24138] ERROR: 3 ring buffer overflows (135 bytes dropped) The picture has big distortions, and typically xine hangs at some point. With traditional Mpeg-streams, there is no problem watching with 1.7.14. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] noad-0.7.1
the Noad kirjoitti: Hi, there is a new version of noad at http://noad.heliohost.org This Version handles also TS-Recordings. A couple of problems: Mar 18 12:54:58 vdr noad[22790]: noad arg[0]: noad Mar 18 12:54:58 vdr noad[22790]: noad arg[1]: - Mar 18 12:54:58 vdr noad[22790]: noad arg[2]: /video0/elokuvat/Elokuva:_Oven_tak ana_(K15)/2010-02-21.20.58.4-0.rec Mar 18 12:54:58 vdr noad[22790]: noad args done Mar 18 12:54:58 vdr noad[22790]: Thursday,18.03.2010 12:54:58 start noad-0.7.1 for /video0/elokuvat/Elokuva:_Oven_takana_(K15)/2010-02-21.20.58.4-0.rec Mar 18 13:04:58 vdr noad[22790]: [22790] ERROR: frame larger than buffer (535048 524144) and another Mar 18 13:03:02 vdr noad[23260]: noad arg[0]: noad Mar 18 13:03:02 vdr noad[23260]: noad arg[1]: nice Mar 18 13:03:02 vdr noad[23260]: noad arg[2]: /video0/Kettu/VikkelE4t_tassut:_Kettu/2010-03-02.07.24.2-0.rec Mar 18 13:03:02 vdr noad[23260]: noad args done Mar 18 13:03:02 vdr noad[23260]: Thursday,18.03.2010 13:03:02 start noad-0.7.1 for /video0/Kettu/VikkelE4t_tassut:_Kettu/2010-03-02.07.24.2-0.rec Mar 18 13:03:28 vdr noad[23260]: [23260] ERROR: 'I' frame at end of file #42956 Mar 18 13:03:28 vdr noad[23260]: noad aborted by signal Segmentation fault Mar 18 13:03:28 vdr noad[23260]: [bt] Execution path: Mar 18 13:03:28 vdr noad[23260]: [bt] noad(_Z15show_stackframeb+0x1a) [0x41a34a] Mar 18 13:03:28 vdr noad[23260]: [bt] noad [0x418a7f] Mar 18 13:03:28 vdr noad[23260]: [bt] /lib/libc.so.6 [0x7f1237ec8fc0] Mar 18 13:03:28 vdr noad[23260]: [bt] noad(_Z10demuxFrameP9cFileNametlii+0x36) [0x425b06] Mar 18 13:03:28 vdr noad[23260]: [bt] noad(_Z9checkLogoP9cFileNamei+0xb9) [0x40d089] Mar 18 13:03:28 vdr noad[23260]: [bt] noad(_Z10detectLogoP9cFileNamePci+0x11a) [0x40e41a] Mar 18 13:03:28 vdr noad[23260]: [bt] noad(_Z10scanRecordiP6cMarks+0x1fa) [0x41372a] Mar 18 13:03:28 vdr noad[23260]: [bt] noad(_Z9doX11ScanP8noadDataPKci+0x47) [0x414097] Mar 18 13:03:28 vdr noad[23260]: [bt] noad(_Z6doNoadbPKc+0x1ab) [0x418ebb] Mar 18 13:03:28 vdr noad[23260]: [bt] noad(main+0x774) [0x4196c4] Mar 18 13:03:28 vdr noad[23260]: [bt] /lib/libc.so.6(__libc_start_main+0xfd) [0x7f1237eb5abd] Mar 18 13:03:28 vdr noad[23260]: [bt] noad [0x409f59] yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] noad-0.7.1
Jouni Karvo kirjoitti: the Noad kirjoitti: Hi, there is a new version of noad at http://noad.heliohost.org This Version handles also TS-Recordings. A couple of problems: Mar 18 12:54:58 vdr noad[22790]: noad arg[0]: noad Mar 18 12:54:58 vdr noad[22790]: noad arg[1]: - Mar 18 12:54:58 vdr noad[22790]: noad arg[2]: /video0/elokuvat/Elokuva:_Oven_tak ana_(K15)/2010-02-21.20.58.4-0.rec Mar 18 12:54:58 vdr noad[22790]: noad args done Mar 18 12:54:58 vdr noad[22790]: Thursday,18.03.2010 12:54:58 start noad-0.7.1 for /video0/elokuvat/Elokuva:_Oven_takana_(K15)/2010-02-21.20.58.4-0.rec Mar 18 13:04:58 vdr noad[22790]: [22790] ERROR: frame larger than buffer (535048 524144) For the first problem: It seems that vdr_cl.h has MAXFRAMESIZE defined as #define MAXFRAMESIZE (KILOBYTE(512) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE to avoid breaking up TS packets vdr has: #define MAXFRAMESIZE (KILOBYTE(1024) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE to avoid breaking up TS packets So I'm trying with that larger one, in case it helps. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDSB revisited
Markus Fritsche kirjoitti: I am using v1.6.0 (which came with Ubuntu) - is it outdated? Ah. I guess not - my bad. The latest development version is 1.7.12, and I made a wrong assumption. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDSB revisited (was: Re: Tuning USB)
I have a similar problem - for some reason VDSB without a real explanation. Markus Fritsche kirjoitti: Hello All, The issue was not related to USB whatsoever - my channels.conf was the issue. I created it with scan from the dvb-utils package. Turns out that scan -o vdr outputs the channel frequency in kHz, where vdr expects it in Hz. Obviously, the vdr still tunes but the recording part is baffled. Refer also too: http://www.vdr-portal.de/board/thread.php?threadid=88654 This is weird. dvbdevice.c has the function FrequencyToHz that is used for DVB-T and DVB-C. That should make the conversion automatically. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.11 (+ vdr-xine) segfaults
Jouni Karvo kirjoitti: So it seems the syscall numbers have changed at some point. I am afraid if the libc is now broken due to this. This has not happened to me before, so I don't actually know what would be the good thing to do. But forcing the syscall number to 178 does not actually fix the thread numbers in the log file. OK. So now I have updated from lenny to squeeze, and the thread-numbers appear now OK. Let's see if the actual problem persists, or not. I'll report then back, if it does. Thank you for your help. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.11 (+ vdr-xine) segfaults
hi, Reinhard Nissl kirjoitti: Please report the logged error message. Actually, your patch immediately segfaulted. But I can see some problem: The include files from the distro tell me: k...@vdr:/usr/include$ grep __NR_gettid */* asm/unistd_32.h:#define __NR_gettid224 asm/unistd_64.h:#define __NR_gettid186 asm/unistd_64.h:__SYSCALL(__NR_gettid, sys_gettid) bits/syscall.h:#define SYS_gettid __NR_gettid but the kernel includes tell: k...@vdr:/usr/src/linux/include$ grep __NR_gettid */* asm-generic/unistd.h:#define __NR_gettid 178 asm-generic/unistd.h:__SYSCALL(__NR_gettid, sys_gettid) So it seems the syscall numbers have changed at some point. I am afraid if the libc is now broken due to this. This has not happened to me before, so I don't actually know what would be the good thing to do. But forcing the syscall number to 178 does not actually fix the thread numbers in the log file. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.11 (+ vdr-xine) segfaults
... and here the backtrace without -O2, if it helps more...
#0 0x004717be in cHashObject::Object (this=0x41) at tools.h:525
525 cListObject *Object(void) { return object; }
(gdb) bt
#0 0x004717be in cHashObject::Object (this=0x41) at tools.h:525
#1 0x00470153 in cChannels::GetByChannelID (this=0x7951a0,
ChannelID=
{source = 16384, nid = 42249, tid = 26, sid = 1, rid = 0, static
InvalidID = {source = 0, nid = 0, tid = 0, sid = 0, rid = 0, static
InvalidID = same as static member of an already seen type}},
TryWithoutRid=true,
TryWithoutPolarization=false) at channels.c:1086
#2 0x0049cddc in cEIT (this=0x41e49fb0, Schedules=0x79cb00,
Source=16384, Tid=79 'O', Data=0x41e4a0a0 O?\033,
OnlyRunningStatus=false) at eit.c:36
#3 0x0049e343 in cEitFilter::Process (this=0x7f0610005230, Pid=18,
Tid=79 'O', Data=0x41e4a0a0 O?\033, Length=286) at eit.c:382
#4 0x004f8b09 in cSectionHandler::Action (this=0x7f06100091a0)
at sections.c:212
#5 0x0051d739 in cThread::StartThread (Thread=0x7f06100091a0)
at thread.c:257
#6 0x7f061d2dffc7 in start_thread () from /lib/libpthread.so.0
#7 0x7f061bfed59d in clone () from /lib/libc.so.6
#8 0x in ?? ()
Current language: auto; currently c++
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.11 (+ vdr-xine) segfaults
hi,
I just turned to 64bit, and it seems vdr dumps core there...
compiled with g++-4.3
command line:
`./vdr-prod -u vdr -w 60 -P xine -v /video0 -c /video0 --userdump -l 3'
log content (end of log):
Script done on Mon 25 Jan 2010 07:28:00 PM EET
Jan 25 19:26:20 vdr vdr: [-1] channel 1 (TV1) event Mon 25.01.2010
19:00-19:50 'Prisma: Kun jää sulaa' status 4
Jan 25 19:26:23 vdr vdr: [-1] buffer usage: 70% (tid=-1)
Jan 25 19:26:24 vdr vdr: [-1] buffer usage: 80% (tid=-1)
Jan 25 19:26:25 vdr vdr: [-1] buffer usage: 90% (tid=-1)
Jan 25 19:26:26 vdr vdr: [-1] buffer usage: 100% (tid=-1)
Jan 25 19:27:18 vdr vdr: [-1] PANIC: watchdog timer expired - exiting!
and backtrace:
Script started on Mon 25 Jan 2010 07:27:38 PM EET
v...@vdr:~/vdr-1.7.11$ gx[Kdb --core core ./vdr-prod
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu...
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libjpeg.so.62...done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libcap.so.1...done.
Loaded symbols for /lib/libcap.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /usr/lib/libfreetype.so.6...done.
Loaded symbols for /usr/lib/libfreetype.so.6
Reading symbols from /usr/lib/libfontconfig.so.1...done.
Loaded symbols for /usr/lib/libfontconfig.so.1
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libexpat.so.1...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
Reading symbols from /usr/lib/gconv/ISO8859-2.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-2.so
Reading symbols from /usr/lib/gconv/ISO8859-15.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-15.so
Reading symbols from /usr/lib/gconv/ISO8859-7.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-7.so
Reading symbols from /usr/lib/gconv/ISO8859-13.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-13.so
Reading symbols from /usr/lib/gconv/ISO8859-5.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-5.so
Reading symbols from /usr/lib/gconv/ISO8859-9.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-9.so
Reading symbols from
/home/vdr/vdr-1.7.11/PLUGINS/lib/libvdr-xine.so.1.7.11...done.
Loaded symbols for ./PLUGINS/lib/libvdr-xine.so.1.7.11
Reading symbols from /usr/lib/gconv/ISO_6937.so...done.
Loaded symbols for /usr/lib/gconv/ISO_6937.so
Core was generated by `./vdr-prod -u vdr -w 60 -P xine -v /video0 -c
/video0 --userdump -l 3'.
Program terminated with signal 11, Segmentation fault.
[New process 11362]
[New process 11879]
[New process 12465]
[New process 11873]
[New process 10833]
[New process 11364]
[New process 11361]
[New process 11874]
[New process 10763]
[New process 11875]
[New process 11876]
[New process 11877]
[New process 12464]
[New process 11348]
[New process 11349]
#0 cChannels::GetByChannelID (this=value optimized out, ChannelID=
{source = 16384, nid = 15, tid = 3, sid = 64000, rid = 0, static
InvalidID = {source = 0, nid = 0, tid = 0, sid = 0, rid = 0, static
InvalidID = same as static member of an already seen type}},
TryWithoutRid=true, TryWithoutPolarization=false) at channels.c:1086
1086 cChannel *channel = (cChannel *)hobj-Object();
(gdb) bt
#0 cChannels::GetByChannelID (this=value optimized out, ChannelID=
{source = 16384, nid = 15, tid = 3, sid = 64000, rid = 0, static
InvalidID = {source = 0, nid = 0, tid = 0, sid = 0, rid = 0, static
InvalidID = same as static member of an already seen type}},
TryWithoutRid=true, TryWithoutPolarization=false) at channels.c:1086
#1 0x0047f562 in cEIT (this=0x42e68f90, Schedules=0x74d980,
Source=16384,
Tid=96 '`', Data=value optimized out, OnlyRunningStatus=false) at
eit.c:36
#2 0x00480cee in cEitFilter::Process (this=0x7fdca0479e70,
Pid=value optimized out, Tid=value optimized out,
Data=0x42e690d0 `ñÇú,
Length=value optimized out) at eit.c:382
#3
Re: [vdr] vdr-1.7.11 (+ vdr-xine) segfaults
Jouni Karvo kirjoitti: hi, I just turned to 64bit, and it seems vdr dumps core there... compiled with g++-4.3 answering to myself. Compiling with g++-4.1 removes the segmentation fault. I don't know whether this is related, but g++-4.3 warns in many places about expressions with both and || and recommends adding parenthesis. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dynamic PIDs
Klaus Schmidinger kirjoitti: On 24.11.2009 22:38, Anssi Hannula wrote: Klaus Schmidinger wrote: On 24.11.2009 19:22, Anssi Hannula wrote: Klaus Schmidinger wrote: On 24.11.2009 18:28, Jouni Karvo wrote: Jouni Karvo kirjoitti: Rolf Ahrenberg kirjoitti: On Mon, 23 Nov 2009, Jouni Karvo wrote: is there somewhere a patch that would remove the break when the broadcaster uses dynamic pids (such as YLE). Now, when a programme starts at YLE, they change the Audio PID number, leading to VDR re-tuning or something, that leads to a 1-2s break in the show. There is no change in frequency, so I don't see any reason why there is such a break. As a quick fix just disable the pid updates (Channel update: no/names only). Yle is always using the same pid numbers although they're switching them on and off, so you can easily fix these numbers in your channel.conf. Tried this, but it seems it loses the subtitling PIDs. Is there a way to get both - subtitling and non-breaking TV viewing? It might be interesting to learn why they do this PID cycling in the first place. Have you ever tried contacting them and asking why they do such a stupid thing? Different programmes have a different number of languages, so the number of active pids changes. Isn't that correct behaviour? Sure, but why cycle them through various values, and not use the same ones for the same languages? As far as I can see they keep them the same, and VDR retunes just because the number of tracks changes. As long as the PID switch takes place outside a show, that's of course ok. Switching them *inside* a show is IMHO not a good idea. The change of active PIDs takes place when a show begins, causing 1-2s of stream to go missing due to the retune as Jouni described in the initial post. It sure wouldn't hurt if they changed the PIDs a little earlier. Other channels do that. True. I don't know, however, if it is reasonable to request YLE to change the pids before the actual programme stream starts. It seems things look clearer. When the show starts, then within 1-2 seconds the break starts, then there is the break of 1-2 seconds, after that everything is smooth. The biggest actual annoyance is that nowadays the titles are often after the first scene, so there is a part of the actual show right in the beginning. It often happens that about 30 seconds of subtitling is lost at the beginning of the show; probably as it is sent during those precious first seconds. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dynamic PIDs
Klaus Schmidinger kirjoitti: On 23.11.2009 18:36, Jouni Karvo wrote: hi, is there somewhere a patch that would remove the break when the broadcaster uses dynamic pids (such as YLE). Now, when a programme starts at YLE, they change the Audio PID number, leading to VDR re-tuning or something, that leads to a 1-2s break in the show. There is no change in frequency, so I don't see any reason why there is such a break. VDR simply retunes whenever the PIDs or other parameters change. It just keeps things simple ;-) I appreciate this KISS approach. Changing the PIDs while a broadcast is already running is not a very good practice... Well. They probably think it is very much using the possibilities of the new technology. Luckily they do not switch them during news broadcasts, when interviewing foreign people. Now that would be a nightmare. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dynamic PIDs
Jouni Karvo kirjoitti: Rolf Ahrenberg kirjoitti: On Mon, 23 Nov 2009, Jouni Karvo wrote: is there somewhere a patch that would remove the break when the broadcaster uses dynamic pids (such as YLE). Now, when a programme starts at YLE, they change the Audio PID number, leading to VDR re-tuning or something, that leads to a 1-2s break in the show. There is no change in frequency, so I don't see any reason why there is such a break. As a quick fix just disable the pid updates (Channel update: no/names only). Yle is always using the same pid numbers although they're switching them on and off, so you can easily fix these numbers in your channel.conf. Tried this, but it seems it loses the subtitling PIDs. Is there a way to get both - subtitling and non-breaking TV viewing? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.9 fails to record one channel
Jouni Karvo kirjoitti: hi, I have the following problem: When live viewing with 1.7.9 and vdr-xine 0.9.3, this channel (in cable) is shown properly: TV7;HTV:386:M128:C:6900:800+802=2:801=fin:0:0:61500:42249:16:0 vdr-1.7.10 seems to fix this. Thanks! yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Dynamic PIDs
hi, is there somewhere a patch that would remove the break when the broadcaster uses dynamic pids (such as YLE). Now, when a programme starts at YLE, they change the Audio PID number, leading to VDR re-tuning or something, that leads to a 1-2s break in the show. There is no change in frequency, so I don't see any reason why there is such a break. Or is this a problem of co-operation with vdr-xine, instead of tuning the card? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.7.9 fails to record one channel
hi, I have the following problem: When live viewing with 1.7.9 and vdr-xine 0.9.3, this channel (in cable) is shown properly: TV7;HTV:386:M128:C:6900:800+802=2:801=fin:0:0:61500:42249:16:0 If I try to record anything, vdr restarts constantly, and the recording is of zero length. The output of vdr (or xine) says: DiscontinuityDetected: triggering soft start With 1.7.7 and the same vdr-xine version, recording works, but vdr is not able to jump forward or backward in the recording. 1.7.9 is also able to show the recordings made with 1.7.7 (but not able to jump forward or backwards.) Any debugging hints? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 1.7.7 and recorded subtitles
hi, Now having some experiences with vdr-1.7.7. It seems subtitles are OK in live view, and with new recordings. But when viewing recordings made with 1.5.7 (my previous version), the subtitles are shown much too early. It seems they appear right after the previous text should be shown, are kept on the screen the correct amount of time and then disappear. Typically they are already gone when the actual speaking starts. Any patch hanging around fixing this? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.7 + osdteletext
Tobi kirjoitti: Jouni Karvo wrote: I installed vdr-1.7.7, yaepghd patch, and osdteletext. For some reason, I don't seem to get any data to the teletext pages. The /vtx directory also stays empty. Any ideas on how to debug or what to do? Make sure, you use the latest osdteletext version, which is 0.8.1. The default vtx location is now more FHS-conform: /var/cache/vdr/vtx (can be changed with --directory) http://projects.vdr-developer.org/projects/show/plg-osdteletext Ah, thanks. I used 0.8.1, but did not notice that the directory had changed, and noticed no error messages. Making a symbolic link from the new location to the old made the trick. thanks, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.7 + osdteletext
hi, I decided to upgrade after about two years with an old, stable(ish) version. I installed vdr-1.7.7, yaepghd patch, and osdteletext. For some reason, I don't seem to get any data to the teletext pages. The /vtx directory also stays empty. Any ideas on how to debug or what to do? I did not find any patches for osdteletext and the new vdr-versions. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] yaepghd-plugin
hi, I am using yaepghd + vdr-xine 9.2. The small window showing the current channel does not scale the video down, but only shows a small fraction of the normal-sized video window. Any idea on how to make the video scale for the window? I run xine with this command: /usr/local/bin/xine -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 -L -A alsa -a spdif --no-splash -g -f -V xv vdr://tmp/vdr-xine/stream#demux:mpeg_pes --post vdr_video --post vdr_audio yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] yaepghd-plugin
VDR User kirjoitti: On Tue, May 12, 2009 at 7:48 AM, Jouni Karvo jouni.ka...@iki.fi wrote: hi, I am using yaepghd + vdr-xine 9.2. The small window showing the current channel does not scale the video down, but only shows a small fraction of the normal-sized video window. Any idea on how to make the video scale for the window? I looked into this before and apparently support has to be added to xine-lib for it. I would email Darren Salt, the xine-dev mailing list, or join #xine on freenode and inquire there. Ah, actually, all I needed to do was to edit one setting in the vdr-xine Makefile. Working finely now! ... now I just need to find a way to open the recording dialog in yaepghd. This one is not trivial. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
VDR User kirjoitti: On Thu, May 7, 2009 at 11:38 AM, Jouni Karvo jouni.ka...@iki.fi wrote: I'd be pleased, if there would be some kind of a caretaking, so that the pause-live-tv recording would just disappear after returning to other modes of operation. I think it would not break anything for the user, since you can always use the specific recording button in the menu to create an actual recording. If you want to pause live tv, how else would you suggest caching the stream? It's either going to be to ram or some storage device, and if you don't save the stream (aka record it), how are you supposed to play it back? Unless you mean VDR should somehow determine that you've caught up to live tv from playing back at the point you paused it, and then delete the recording/cache without caring if you wanted to keep it for any reason. I really hope Klaus never intends to implement something like the live tv buffer that myth has. The idea of one of my harddrives saving nonstop 24/7 is really really lame. Huge waste of power, constant heat, and unnecessary wear on the harddrive for something that probably doesn't even get used that much in the first place. No, I meant deleting automatically the pause-live-TV recording. That recording is conceptually just a technical implementation issue (and should not be visible in the recordings list, even, in my opinion). The end user needs not care for the object structure of VDR source code, and the implementation of pause-live-TV is in the same category. It is easy to distinguish pausing live TV and making a recording as concepts, as a normal user. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
Frank Scherthan kirjoitti: Hi there :) marti...@embl.de schrieb: Well, keeping the remote control away from my kids is not easy unless I han g it from the ceiling. Is there some way I can disable live tv pausing all together? It is causing a lot of trouble and I don´t reallly need that feature... I really don't understand the whole discussion that is going on here. This behavior is intented. Pressing pause in Live-View starts a recording and pauses it. This is a great feature and I really would miss that! Yes - that is great. But... I'd be pleased, if there would be some kind of a caretaking, so that the pause-live-tv recording would just disappear after returning to other modes of operation. I think it would not break anything for the user, since you can always use the specific recording button in the menu to create an actual recording. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Klaus Schmidinger kirjoitti: On 23.03.2009 22:13, Klaus Schmidinger wrote: On 23.03.2009 21:42, Niedermeier Günter wrote: Here's a quick shot - totally untested (no time, sorry). Please try it and let me know if it helps. Hi, I've tried it: files are created, but with zero filesize. Only info is correct. After a few seconds vdr is restarting with an emergency exit!. Well, then I guess I do need to spend a little more time on this ;-) I hope the patch does what I thought it would: collects writes in larger chunks. For a networked application, the key performance bottleneck is the number of needed transactions. See e.g. http://portal.acm.org/citation.cfm?id=1066051.1066069 (and the PDF file in there). yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] why I must first compile xine-lib?not ffmpeg?
LinHai kirjoitti: I apt-get install libfaad-dev,but the log: Please include also the error messages, not only the report of make quitting. It is difficult to help if you do not give enough information. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] why I must first compile xine-lib，n ot ffmpeg?
LinHai kirjoitti: when I first compile xine-lib is OK，second compile ffmpeg is OK. IF I first compile ffmpeg is OK，second compile xine-lib is failure. the syslog: make[2]: *** [xineplug_decode_faad_la-xine_faad_decoder.lo] Error 1 make[2]: Leaving directory `/root/xine-lib-1-2-926ee2edf0d8/src/audio_dec' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/xine-lib-1-2-926ee2edf0d8/src' make: *** [all-recursive] Error 1 why ,who can tell me? My guess is you have not installed libfaad or libfaad includes, or neither. But including the error messages could help in finding the cause. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] compiling the xine-1.2 with external ffmpeg
Goga777 kirjoitti: I just compiled the hg xine-lib 1.2 with SVN ffmpeg. In case someone is interested in the same, these are the options required for xine-lib: ./autogen.sh --with-external-ffmpeg /usr/src/xine-lib-1.2# ./configure --help | grep ffmpeg /usr/src/xine-lib-1.2# no need to use now --with-external-ffmpeg option for hg xine-lib 1.2 Good to know. The include and linking parameters for autogen.sh solved the compilation problems, and were probably my main message, though. xine-lib 1.2 hg is (I guess) compatible with an older version of ffmpeg than the repository one. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] compiling the xine-1.2 with external ffmpeg
hi, I just compiled the hg xine-lib 1.2 with SVN ffmpeg. In case someone is interested in the same, these are the options required for xine-lib: ./autogen.sh --with-external-ffmpeg CPPFLAGS=-I/usr/local/include/libavcodec -I/usr/local/include/libavdevice -I/usr/local/include/libavformat -I/usr/local/include/libavutil -I/usr/local/include/libpostproc -I/usr/local/include/libyasm -I/usr/include FFMPEG_LIBS=-L/usr/local/lib -lavcodec -lavformat -lavdevice -lavutil -lz After this, a simple make + make install works. To get xine-ui to compile, I needed to * change the order of the lines starting datadir= and datarootdir= in /usr/local/lib/pkgconfig/libxine.pc, and give * give the pkgconfig-parameter: ./configure PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ...and again, then a simple make + make install will work. Seems to work now - haven't tested H.264 yet, though. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR not starting if a plugin fails to start?
Petri Helin wrote: really causes VDR to not start also. My aim really was to start some discussion on whether that should be changed. I myself think that VDR should start although some plugin fails to start. I'd hate to find out that some timed recording failed because the lcd display of the PC case malfunctioned. Why not design plugins that start even if some non-fatal error happens? To me it sounds natural that if some non-recoverable error happens, the whole program stops. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
On Wed, Aug 13, 2008 at 09:09:45PM +0100, Gavin Hamill wrote: So, I started looking for other reasons. Whilst X + vdr are running, the Xorg process is taking 40% CPU, with vdr taking 25%. The 'system' CPU usage is 32%, with 16% for user processes. I thought maybe it was using X11 output rather than xv, and thus causing a drain on the system... Have you checked that your display driver is OK? MTRR? Are you sure you use e.g. XV and not XShm? Also, VDR taking 25% of resources looks pretty high. Can you check without plugins? (or is the 25% already including a software player?) yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
hi, Thomas Hilber wrote: On Mon, Aug 11, 2008 at 07:40:15PM +0300, Jouni Karvo wrote: with NVIDIA driver 169 and 173 at least, this does not yet work: I cannot confirm that. I just downloaded and installed most recent NVIDIA-Linux-x86-173.14.12.pkg1.run It's running perfectly VGA-SCART with *exactly* the xorg.conf I posted above. your trick is the VGA-SCART cable. I was using the TVout from the card. I have ordered the components for the cable, and I hope I'll be able to solder them together during the weekend. I hope I can then reproduce your success :) yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate
hi, with NVIDIA driver 169 and 173 at least, this does not yet work: Thomas Hilber kirjoitti: I just use one big hammer instead:) Option UseEDID FALSE That works (mostly). And the reason is easily read from the driver's README: Because these TV modes only depend on the TV encoder and the TV standard, TV modes do not go through normal mode validation. The X configuration options HorizSync and VertRefresh are not used for TV mode validation. Additionally, the NVIDIA driver contains a hardcoded list of mode sizes that it can drive for each combination of TV encoder and TV standard. Therefore, custom modelines in your X configuration file are ignored for TVs. Setting TV format to PAL-B results in the following modeline (with prefedined 720x576): DISPLAY=:0.0 xvidtune -show 720x576 31.50720 760 840 880576 585 588 597 -hsync -vsync and PAL-G: DISPLAY=:0.0 xvidtune -show 720x576 31.50720 760 840 880576 585 588 597 -hsync -vsync (does not change at all...) I have no idea on whether this is 50Hz or 60Hz - I guess not interlaced at least. So the question is if you have used VGA instead of TVout, or tricked the driver somehow to respect your own modelines... I add the relevant part of Xorg.0.log, so you can see what the modelines available are: (**) NVIDIA(0): Ignoring EDIDs (II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is (II) NVIDIA(0): enabled. (II) NVIDIA(0): NVIDIA GPU GeForce FX 5200 (NV34) at PCI:1:0:0 (GPU-0) (--) NVIDIA(0): Memory: 131072 kBytes (II) NVIDIA(0): GPU RAM Type: DDR1 (--) NVIDIA(0): VideoBIOS: 04.34.20.87.00 (--) NVIDIA(0): Found 2 CRTCs on board (II) NVIDIA(0): Supported display device(s): CRT-0, CRT-1, DFP-0, TV-0 (II) NVIDIA(0): Bus detected as AGP (II) NVIDIA(0): Detected AGP rate: 8X (--) NVIDIA(0): Interlaced video modes are supported on this GPU (II) NVIDIA(0): (II) NVIDIA(0): Mode timing constraints for : GeForce FX 5200 (II) NVIDIA(0): Maximum mode timing values : (II) NVIDIA(0): Horizontal Visible Width : 8192 (II) NVIDIA(0): Horizontal Blank Start : 8192 (II) NVIDIA(0): Horizontal Blank Width : 4096 (II) NVIDIA(0): Horizontal Sync Start: 8184 (II) NVIDIA(0): Horizontal Sync Width: 504 (II) NVIDIA(0): Horizontal Total Width : 8224 (II) NVIDIA(0): Vertical Visible Height : 8192 (II) NVIDIA(0): Vertical Blank Start : 8192 (II) NVIDIA(0): Vertical Blank Width : 256 (II) NVIDIA(0): Veritcal Sync Start : 8191 (II) NVIDIA(0): Vertical Sync Width : 15 (II) NVIDIA(0): Vertical Total Height: 8193 (II) NVIDIA(0): (II) NVIDIA(0): Minimum mode timing values : (II) NVIDIA(0): Horizontal Total Width : 40 (II) NVIDIA(0): Vertical Total Height: 2 (II) NVIDIA(0): (II) NVIDIA(0): Mode timing alignment: (II) NVIDIA(0): Horizontal Visible Width : multiples of 8 (II) NVIDIA(0): Horizontal Blank Start : multiples of 8 (II) NVIDIA(0): Horizontal Blank Width : multiples of 8 (II) NVIDIA(0): Horizontal Sync Start: multiples of 8 (II) NVIDIA(0): Horizontal Sync Width: multiples of 8 (II) NVIDIA(0): Horizontal Total Width : multiples of 8 (II) NVIDIA(0): (--) NVIDIA(0): Connected display device(s) on GeForce FX 5200 at PCI:1:0:0: (--) NVIDIA(0): NVIDIA TV Encoder (TV-0) (--) NVIDIA(0): NVIDIA TV Encoder (TV-0): 350.0 MHz maximum pixel clock (--) NVIDIA(0): TV encoder: NVIDIA (II) NVIDIA(0): TV modes supported by this encoder: (II) NVIDIA(0): 1024x768; Standards: NTSC-M, NTSC-J, PAL-M, PAL-BDGHI, (II) NVIDIA(0): PAL-N, PAL-NC (II) NVIDIA(0): 800x600; Standards: NTSC-M, NTSC-J, PAL-M, PAL-BDGHI, PAL-N, (II) NVIDIA(0): PAL-NC (II) NVIDIA(0): 720x576; Standards: PAL-BDGHI, PAL-N, PAL-NC (II) NVIDIA(0): 720x480; Standards: NTSC-M, NTSC-J, PAL-M (II) NVIDIA(0): 640x480; Standards: NTSC-M, NTSC-J, PAL-M, PAL-BDGHI, PAL-N, (II) NVIDIA(0): PAL-NC (II) NVIDIA(0): 640x400; Standards: NTSC-M, NTSC-J, PAL-M, PAL-BDGHI, PAL-N, (II) NVIDIA(0): PAL-NC (II) NVIDIA(0): 400x300; Standards: NTSC-M, NTSC-J, PAL-M, PAL-BDGHI, PAL-N, (II) NVIDIA(0): PAL-NC (II) NVIDIA(0): 320x240; Standards: NTSC-M, NTSC-J, PAL-M, PAL-BDGHI, PAL-N, (II) NVIDIA(0): PAL-NC (II) NVIDIA(0): 320x200; Standards: NTSC-M, NTSC-J, PAL-M, PAL-BDGHI, PAL-N, (II) NVIDIA(0): PAL-NC (II) NVIDIA(0): Frequency information for NVIDIA TV Encoder (TV-0): (II) NVIDIA(0): HorizSync : 15.000-16.000 kHz (II) NVIDIA(0): VertRefresh : 43.000-72.000 Hz (II) NVIDIA(0): (HorizSync from HorizSync in X Config Monitor section) (II) NVIDIA(0): (VertRefresh from Conservative Defaults) (II) NVIDIA(0): Note that the HorizSync and VertRefresh frequency ranges are (II) NVIDIA(0): ignored for TV Display Devices; modetimings for TVs will (II) NVIDIA(0): be selected based on the capabilities of the NVIDIA TV (II) NVIDIA(0): encoder. (II) NVIDIA(0):
Re: [vdr] vdr-restarts after upgrade
hi, Oliver Joa wrote: Hi, i recently upgraded my vdr to version 1.6.0. Now my vdr restarts every some minutes when recording: If it only happens when recording encrypted channels, but not when live viewing, then it can be a problem of too short a timeout. At some point I had such a problem - the card did not start delivering video fast enough for encrypted channels. The answer was to just remove the emergency exit in the VDR main loop. Then it worked fine. But that was for an earlier version of VDR. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: viewing 16:9 content on 4:3 output device
Ian Bates wrote: One more remark, if as I believe from the comments in the code above, that the '16:9 crop to 4:3' behaviour is not implemented in xineliboutput, am I the only one suffering from the lack of this feature? Am I the only one still using a 4:3 TV? I don't think so, what do other people do when viewing 16:9 material on a 4:3 device, other than put up with the black bars? I also use a 21 4:3 old CRT TV for all DVD and TV. And I want to see the whole picture, as the others who have responded. There is another reason, in addition to the real estate reason of throwing away a lot of paid content (how wasteful!). Namely, the composition of the images is designed for the format they are shown in, at least in quality material. So, filling the whole screen means you do not see the material's photographic value. I hope some day I'm able to bite the bullet and move to the Full HD panel TV world, but so far the old faithful has served well. Nevertheless, although probably most techies feel the crop mode is not interesting, perhaps you'll be able to find one that is willing to implement it - or perhaps you can DIY and share the code. Good luck. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hearing-impaired DVB subtitles
Klaus Schmidinger kirjoitti: However, there still would be the problem that VDR couldn't even tell that the dut track is for the hard of hearing, because it is not properly marked. Or am I missing something here? I think you are right - YLE uses dut for a synonym of hearing impaired. Go figure. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine problems with vdr
Morfsta kirjoitti: On Feb 7, 2008 4:27 PM, Jouni Karvo [EMAIL PROTECTED] wrote: The --stdctl option causes xine to crash if it is used when starting from the script... Someone advised me of a workaround, you can use the startup script with a sudo xine, or a su - xine and it will not segfault. I guess using su or sudo setup some different environment variables (or something) that xine is happy with. Ah. But I used su already, and -l (or -) did not help, so this --stdctl bug is a different bug. Well, anyway. There seems to be something else wrong, too, as some streams (namely the IPTV-ones) have audio when xine is started as a user, but not when started from a script. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine problems with vdr
hi, I found the problem actually right after sending the email (but it is still a bug in xine): XINECMD=$XINEPRG -L -A alsa -a spdif --no-splash -g -f -V xv --stdctl vdr://tmp/vdr-xine/stream#demux:mpeg_pes --post vdr_video --post vdr_audio --verbose=2 The --stdctl option causes xine to crash if it is used when starting from the script... gdb backtrace: Core was generated by `/usr/local/bin/xine -L -A alsa -a spdif --no-splash -g -f -V xv --stdctl vdr://'. Program terminated with signal 11, Segmentation fault. #0 0x080f888c in destroy_oxine (oxine=0x0) at oxine.c:710 710 if (oxine-otk) otk_free(oxine-otk); (gdb) bt #0 0x080f888c in destroy_oxine (oxine=0x0) at oxine.c:710 #1 0x080f8906 in oxine_exit () at oxine.c:731 #2 0x08050a1c in gui_exit (w=0x0, data=0x0) at actions.c:607 #3 0x080592d8 in gui_execute_action_id (action=ACTID_QUIT) at event.c:564 #4 0x0809a6e8 in xine_stdctl_loop (dummy=0x0) at stdctl.c:152 #5 0xb7c2a240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0xb7d0249e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-0.0.5 + vdr-xine audio problem
Ville Skyttä kirjoitti: On Tuesday 22 January 2008, Darren Salt wrote: This patch should fix it. If you find that it works, report back and I'll make sure that it gets committed. I'm not using any xine related functionality with VDR, but I tried the patch below. Unfortunately it makes things even worse for me with Amarok than vanilla 1.1.9.1 - with vanilla 1.1.9.1 audio was ok until I tried to play a radio With this patch, all error messages are gone (except for this) video_out: thread created audio_out: thread created xine_interface: unknown or deprecated stream param 10 set xine_stream_new xine_interface: unknown or deprecated stream param 10 set xine_stream_new xine_interface: unknown or deprecated stream param 10 set ...but so is audio. With the patch, all normal TV channels also are dead quiet. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-0.0.5 + vdr-xine audio problem
hi, I am baffled... Antti Seppälä kirjoitti: Set up a vlc for transcoding in a similar fashion as to how iptv plugin Now open another instance of vlc to play back the transcoded stream: vlc udp://@:4321 works If the stream works perfectly, you can close the playback vlc and try to play with xine: xine udp://127.0.0.1:4321 works when done as one regular user, but not when done as the regular user with what the regular user with what vdr is run. These users belong to the same group, so both can open audio. Even if I just copy the $HOME/.xine/config file to the other user, it still does not work. It just gives some errors: set_speed 0 audio_alsa_out: Drain call failed. (err=-11:Resource temporarily unavailable) bufing: 1, enb: 1 net_buf_ctrl: vid 0% 0.0s0kbps 0, aud 0% 0.0s0kbps 0, buf on ^Mdem ux_ts: found no ISO 639 lang bufing: 1, enb: 1 net_buf_ctrl: vid 0% 0.0s0kbps 0, aud 0% 0.0s0kbps 0, buf on net_buf_ctrl: nbc_set_speed_pause set_speed 0 audio_alsa_out: Drain call failed. (err=-11:Resource temporarily unavailable) bufing: 1, enb: 1 After a while these errors disappear, and it just shows: net_buf_ctrl: vid 97% 3.0s 2008kbps 0, aud 45% 3.0s 192kbps 0, on ^Mbufing: 0, enb: 1 net_buf_ctrl: vid 97% 3.0s 2016kbps 0, aud 45% 3.0s 192kbps 0, on ^Mbufing: 0, enb: 1 net_buf_ctrl: vid 98% 3.0s 2024kbps 0, aud 45% 3.0s 192kbps 0, on ^Mbufing: 0, enb: 1 net_buf_ctrl: vid 98% 3.0s 2024kbps 0, aud 45% 3.0s 192kbps 0, on ^Mbufing: 0, enb: 1 net_buf_ctrl: vid 98% 3.0s 2024kbps 0, aud 46% 3.0s 192kbps 0, on ^Mbufing: 0, enb: 1 net_buf_ctrl: vid 98% 3.0s 2008kbps 0, aud 46% 3.0s 192kbps 0, on ^Mbufing: 0, enb: 1 Which looks like it would work, but nothing comes out. Googling did not seem to help here... I really have no idea of which settings to try next. Configuring xine-ui is not really an easy thing. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-iptv-0.0.3
Antti Seppälä kirjoitti: Hello VDR community Iptv plugin developers are pleased to announce a release of vdr-iptv plugin version 0.0.3. This time the plugin includes a couple of bug I see you are already in version 0.0.5 I'd like to try this out - do you know any free channels in the net? I don't have any IPTV subscriptions, but I see there are some sites that claim to provide legal free channels. Unfortunately, the streaming in them is hidden behind some javascript mess. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-iptv-0.0.5 + vdr-xine audio problem
Segers,Jan J.K.T. kirjoitti: have a look here: http://www.global-itv.com/ thanks. I found a couple of channels. It seems that vlc is able to play the stream correctly, with both audio and video by itself. But when I try to use it together with iptv plugin, it seems that for some reason audio is lost. I use vdr-xine for output. Xine output seems like it gets the audio, but it does not get any synchronization info correctly, as it just reports skipping audio: excerpt from the xine logging: plugin mad will be used for audio streamtype 01. audio_alsa_out:open pause_resume=1 output sample rate 48000 audio jump, diff=-2160 set_speed 100 ao_flush (loop running: 1) video discontinuity #25, type is 0, disc_off 0 waiting for audio discontinuity #25 ao_close audio_out: no streams left, closing driver audio discontinuity #25, type is 0, disc_off 0 waiting for in_discontinuity update #25 vpts adjusted with prebuffer to 3418578 ao_flush (loop running: 1) video discontinuity #26, type is 0, disc_off 0 waiting for audio discontinuity #26 audio discontinuity #26, type is 0, disc_off 0 waiting for in_discontinuity update #26 vpts adjusted with prebuffer to 3418610 This is the corresponding stream entry for channels.conf: Bahn TV;IPTV:3:IPTV|EXT|iptvstream.sh|3:P:0:4+3:5:0:0:1:0:0:0 What should I try? yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-0.0.5 + vdr-xine audio problem
Antti Seppälä kirjoitti: I decided to give Bahn TV a try and could also reproduce symptoms of missing audio. It seems that the transcoding engine of vlc gets confused by the audio bitrate setting iptv plugin uses by default. So far I haven't found other channels than Bahn TV that are affected by this. Try lowering the value of ABITRATE found in iptvstream.sh from 320 to e.g. 192. After such a modification the stream worked fine for me. Hi, this does not seem to help. I have three test channels now, all of which give the video: - The Albanian Rrokum TV - which gives also audio. - Bahn TV - only video. Even with ab=192 - BBC One premier (via http://www.global-itv.com/). Only video My xine has w32 (from xine's output: load_plugins: plugin /usr/local/lib/xine/plugins/1.1.9/xineplug_decode_w32dll.so found ) The script sets VPID=parameter+1, APID=parameter+2, SPID=parameter+3 (I wonder why, since if you want to receive simultaneously two consecutive parameter things, they overlap anyway). When looking at the stream info, they show PIDs like 3,4,66. 4,5,66. I wonder what this 66 is and why... yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
[EMAIL PROTECTED] wrote: How does that sound? Complicated. And you did not even consider cases such as: The card is receiving perfectly another channel on the same mux, so tuning to another mux would not be an option. Although it is easy to add conditions like this to the code, it would mean the system would not become stable for people that have no hardware problems (but only the uncontrollable controlled graceful restart loop problem) in a very long time. The solution with three options sounds best: restart always, if no other (working) recordings, never. It is simple and should fix the problem. yours, Jouni -- http://www.tkk.fi/%7ekex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
[EMAIL PROTECTED] wrote: How does that sound? Complicated. And you did not even consider cases such as: ... Because I've seen this restart cycle many times, and only way out of it is editing via [your favorite editor] the timers.conf file. I have seen the problem too. Just removing timers for the failing channel does not help if you use autotimers. The way out of it is to comment out a line or two in recorder.c-file, which I did on Saturday, but my wife lost interest in watching prof. Capellari's investigations during the time it took. But I think you missed my point - which is not a wonder, considering my writing. So I'll try to say it more clearly: - the restarting cycle tries to solve a faulty hardware driver problem for some specific cards - outside the hardware driver - ideally, the driver would work without reloading - reloading is done as it seems the hardware driver will not get fixed. (I hope moving to DVB-S2 will make this problem obsolete, btw.) - as it is just a hack that is in the wrong place, and hopefully later obsolete, a simple solution should be chosen. - the configuration option is a simple solution. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
VDR User wrote: I like these ideas... NO SIGNAL image in recording during no signal. Or that if no signal then no writing to disk. And a warning in the log about a possible incomplete recording cuz of lost signal + identified in recordings menu by a special char like ? maybe. I do not like the idea of an NO SIGNAL image. I don't want any subliminal messages for short losses of video. If you really want to pad the video, then either using the last frame of a black picture should be enough. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Mid range CPU choice
hi, covert covert writes: About to step into the deep end and build my first VDR box. In fact 2 of them at the same time both with the exact same specs. All parts are going to be new. New CPU's are a lot more confusing than the simple days of single cores at fixed clockspeeds. I can't help on the choosing CPUs part, but I can share my experience with a P4 for a VDR. The thermostatic control fans reduce noise, but are not really silent. I replaced both the power unit to a totally fanless one, and my CPU cooler is Scythe Ninja Rev B, which is totally silent (had a Zahlman AlCu7000 if I remember correctly, before). Then I have an additional 120mm fan running slowly inside the box, but that I cannot hear outside. The most noise right now comes from my Seagate Barracuda hard drives, which are pretty quiet, but still noticeable. Especially one of them which has probably bad bearings. I also tried throttling / underclocking the CPU to reduce heat, but my MB starts an annoying whining noise if I do that, so I could not use that. But my advice, if you really want to reduce noise in a VDR, is to go for fanless choices. If you don't do other processing, any current desktop processor would have enough processing power. For Full HD it could be different, though. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] dynamically sized ringbuffers v2
Stone writes: It still wouldn't surprise me if this version caused a few overflows, but hopefully these will be very rare. I'm curious how streamdev will function with these buffer changes. And since I am not convinced that this memory footprint issue is significant, I am concerned if this patch is accepted before all the overflows and problems with live viewing have been solved first. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
AW: [vdr] VDR stops replay due to strong wind condition
hi, martin writes: Emergency Exit _is_ needed in case you have: a FullFeatured and/or CAM system I think the opposite - EmergencyExit is bad in case of CAM. If I understood the mails correctly, emergency exit is only needed for TT FF cards - and there especially for DVB-S. Tero's script sounds a much better solution for that, though. If it works then it should replace the emergency exit (except for the watchdog that helps in case of vdr+plugin race conditions etc.) yours, Jouni ___ 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
Udo Richter writes: into my VDR, as it saved many recordings for me. This fallback is only triggered if a scheduled recording is getting not a single byte of data for at least one minute, so there's IMHO something seriously wrong about Such as CA authorization needing refreshing, and the card waiting for it. Or bad weather outside. it. And in many cases, a clean restart fixes this for me - because for Then you are lucky. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] ATI + mesa driver + vdr-xine = buffer usage : 100% - X freeze
hi, Sébastien Serra writes: When DRI is loaded and 3D acceleration is ON my X server quickly freezes. My log (using ssh) tells me something like Video does not use 3D acceleration, but it does need dri/drm. So you should check that MTRR and DRI/DRM (I don't remember which - direct rendering anyway) are enabled. Check /var/log/Xorg.log or equivalent for any error messages. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine 0.7.10 buffering
hi, Reinhard Nissl writes: If you show the recording's progress menu and switch to play (after a jump to a cutting mark), you'll see that the progress bar advances very quickly by 10 seconds, as VDR sends the recording data as fast as possible (i. e. as fast as your harddisk can supply the data) to xine. Yes, I saw this. As I do not cut recordings, the 10s delay does not matter. Yesterday we watched one recording and did not notice any hickups when the recording jumped to another disk drive, so it does seem to work as expected. Of course there is always the possibility that the disks just happened to be running when the time to change arrived... I think this hint could be found in the vdr-xine manual, as it certainly is useful. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Understanding how vdr's tuning algo works.
hi, I agree this is a off-topic... (but I hope on topic for the mailing list anyway) Reinhard Nissl writes: The use of MAXBROKENTIMEOUT is a last resort of getting a recording recorded when for example the driver or hardware is in a state where only reloading the driver can help out of this situation. Prior to 1.3.x even a lost DiSEqC message while tuning could lead into such situation where the recorder didn't see any input. I understand that, and I also understand that some people have unstable hardware/drivers. I just wonder if this is the right way to deal with it. As I told in an earlier post, I have removed the driver reloading stuff from my runvdr script and had no problems whatsoever. Increasing MAXBROKENTIMEOUT might help in your case, but I would be careful to set it simply to 1 hour. Consider the case where your hardware/driver runs into trouble, then you would loose 1 hour of a recording. Luca Olivetti posted a patch to this thread which initially uses a 10 times higher MAXBROKENTIMEOUT. Maybe this could be an acceptable solution for you, too. The problem is that it can take quite a long time before there is a new authorization packet in the programme stream. As far as I understand, they are customer (or smart card) specific and tell the card which streams it is allowed to allow decrypting, and naturally it is not very useful to spend a very high percentage of the stream for these authorization things. Another solution that has come to my mind is a patch that would tune free cards to the muxes that contain CA stuff. This way they could receive the authorization information and could possibly have new key info whenever it is changed instead of just trying their luck when they should start a recording. But I do not know whether this would work. And it would not be a very beautiful solution in my mind. Btw. I just concluded from this mailing list a couple of weeks ago that I am not the only one with this CA problem. Of course I might have made the wrong conclusion, though. And, my current solution is not to record from encrypted channels. It works quite well. Recently there was a discussion in another thread on this ML concerning the restarting cycle in bad weather conditions, especially when you have more than one recording running on different devices or when you are going to replay a recording. Currently I have no idea whether there should be a rather complex detection logic for real driver issues (given that such a detection logic is feasible) or whether the current detection should simply be dropped. But that's off topic in this thread. I would guess that if your driver hangs it might be difficult to distinguish from the case of just waiting for the worst shower to pass or the encryption authorization to arrive. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Handling of temporarily encrypted channels
hi, Stone writes: With this modification to dvbdevice.c, I wonder if VDR will still crash when a timer goes off on a channel and all the sudden it becomes encrypted. This would normally cause a broken data stream and VDR would do an emergency exit. I gave up recording encrypted channels with VDR a long time ago. The problem is the VDSB error or something that results in a rebooting cycle for the VDR. It tries to solve the problem in a wrong way, assuming that all delays in starting the video stream are due to driver crashes. While, of course, it is natural to have delays in starting to view an encrypted channel, but the driver's have not crashed for perhaps 1.5 years now. When live viewing, VDR is much more patient and is able to wait without the emergency exit until the right authorization information is given to the smartcard, and the decryption starts. This can take even half an hour, or 45 min even in my setup (at least it has taken a couple of times that long). (Of course the provider does not change keys every day, so the longer delays are not frequent.) When VDR tries a timed recording it has no patience to wait for the decryption to start, so it might sometimes succeed (if the provider has not just changed the keys), or then it just destroys all other recordings with the restarting cycle. So it is better not to try to record an encrypted channel. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
hi, Seppo Ingalsuo writes: Jouni Karvo wrote: Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started. I wonder if this would help in xorg.conf Device section Option UseEvents True This alone did not help, but I got this tip and it helped to my random video freeze problems with Nvidia binary driver and Xv. changing from xvmc to xv did. thanks. Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
hi, I have also currently the responsiveness problem. I have a P4 2.4GHz which runs at aout 20% load, so it should not be a performance problem. Currently home-made lirc, vdr-xine and 1.4.1 (and that's why I haven't reported before you started complaining, as I have not had the energy to upgrade lately). Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started. For me, the vdr watchdog helps, but it definitely is not a DVB-driver problem, as I have modified runvdr to _not_ to reload DVB drivers, as that never helps anything anyway. yours, Jouni -- http://www.tkk.fi/%7ekex ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
hi, Reinhard Nissl writes: Are you using xine's video output driver xxmc? yes, I am. I experience deadlocks with this driver on either nVidia or Via EPIA hardware. For example, when you replay a recording and press the pause button: the pause symbol (OSD) will never appear on screen, input_vdr's RPC thread blocks forever, vdr-xine waits for the RPC result while VDR is caught in cXineOsd::Flush(). hmm... it has once locked, and sometimes the pause symbol does not show, but a quick re-pauseing fixes it. I wonder if the slow responses to remote clicking can then be due to the same, or are there several unrelated issues... yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mediamvp and subtitles
hi, Lauri Tischler writes: Maybe Xbox running mediacenter as frontend ? Streaming with xinelibout ? Does it work? Mediacenter web pages seemed to talk only about streaming video files through a network filesystem. Perhaps I did miss that, though. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recording stops and starts again
hi, Klaus Schmidinger writes: Lauri Tischler wrote: I seem to remember that there was a patch to prevent stopping and starting recording if audio-pid changes. Was there ? ... ...but the audio pids are set up at 20:50:18, which is 6 (six!) seconds after the show has begun. I'd say you should contact your broadcaster and complain about this. The audio pids should be set up *before* the show starts. I remember this discussion before. Back then, from VDR version 1.3.24 the decision was to not to restart recording if the PIDs do not change, but only the language codes. It was like that for some 1.3 versions, but shifted quietly back to the old behaviour a bit later. The same arguments here... http://linvdr.org/mailinglists/vdr/2005/04/msg00070.html And some more: From Teemu Rantanen: I wouldn't expect them to change in the middle of a movie, but some documentaries may have interviews and actual film footage in different languages. I haven't yet recorded any that actually change languages in the middle of a show, but just wondering if there is a limit what you can and what you cannot change... ...and then for VDR 1.3.24 this was implemented. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
