Re: [vdr] converting ts to mkv
On Mon, 26 May 2014 13:17:51 +0200 Gerald Dachs v...@dachsweb.de wrote: Am 2014-05-26 05:09, schrieb VDR User: There's no reason to touch the audio/video streams at all unless you actually want to re-encode them for some reason. If all you want is an .mkv rather than a .ts, that can be done in seconds with mkvmerge. Re-encoding in that case is pointless a waste of time. This is all true. Beside that there is no need to extract audio before using handbrake, there is even no need to use mkvmerge if you don't pretend on mkv. I had used an after recording script that just checked with avprobe, whether the video codec is mpeg2video, or h264. If it was mpeg2video I simply renamed the file to .mpeg, and for h264 to .mp4. Every programs known by me played this files without any problems. No need for mkv. It's better to use mkvmerge (or ffmpeg etc for mpeg2) to remultiplex properly. You still don't have to transcode the streams so it doesn't take much longer. Players can't tell how long (in terms of time) TS files are, or how any point in the file corresponds to time for seeking etc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] skipping 5/10 seconds
On Mon, 07 Apr 2014 12:20:37 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: Well, that's something we can talk about. You could make it so that during replay the Left and Right keys perform 5s skips, and the FastForward/-Rewind keys (if present on the user's remote control) still retain their normal function. That sounds like a good idea. We should also discuss making it assymetric ie right could skip forwards 10 seconds and left could go back 5s. That way you can skip through the adverts in fewer steps until you see you've overrun, then do a half skip backwards to get close to the right place. Totem has assymetric skipping, although I think it's something like 60s and 15s-20s. Anyway, I find that useful. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG for BBC TV channels?
On Sun, 9 Mar 2014 09:53:24 -0700 VDR User user@gmail.com wrote: The author of the EEPG plugin has always been very helpful. You should just contact him about adding Freeview HD support. Then you won't have to monkey around with patches and messing with the VDR core. I think concensus is that the patch's code is cleaner than the plugin's. I looked at the plugin code to see if I could work out how to make the Huffman decoding work on standard PIDs for Freeview as well as on Freesat's non-standard ones, and found it too difficult to follow. The original author might not have so much difficulty, but there's also quite a big memory leak which somehow defied my efforts to trace it with valgrind. I use the Debian packages, so all I have to do when there's an update (rare at the moment because it isn't tracking Klaus' developer versions) is ftech the source with one command, copy the patch into the patches folder and compile it with another single command. The hardest part is generating the command to install just the packages I want and miss out the others :-). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG for BBC TV channels?
On Sun, 09 Mar 2014 14:38:48 +0100 Manuel Reimer manuel.rei...@gmx.de wrote: for most of the GB TV channels it is common to only have the current and the next event in the EPG list. I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin. As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get real EPG for those channels? Thank you very much in advance I guess you're using satellite because there was never a problem with the SD channels on DVB-T (Freeview). The eepg plugin supports Freesat and Sky's EPGs, but it has a memory leak and doesn't support Freeview HD, so instead I use a patch which various people have tweaked over time. I can't find a web download site for it or when it was last posted on this list, so if you're interested and others don't mind a 225K attachment I can post it here again. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG for BBC TV channels?
That's an older version of the patch I use. Someone updated it to embed the Huffman tables in the source code (now that the tables are complete/stable there's no advantage to loading them from separate files). More recently I had to edit it again to deal with an API change in VDR 2. On Sun, 09 Mar 2014 16:52:44 +0100 Christopher Reimer v...@creimer.net wrote: I think you are looking for this patch http://www.rst38.org.uk/vdr/ Unfortunately it's quite old. Christopher Am 09.03.2014 15:19, schrieb Tony Houghton: On Sun, 09 Mar 2014 14:38:48 +0100 Manuel Reimer manuel.rei...@gmx.de wrote: for most of the GB TV channels it is common to only have the current and the next event in the EPG list. I did a few tries to work around this problem using EPG parsed from internet services and imported to VDR via xmltv2vdr-Plugin. As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get real EPG for those channels? Thank you very much in advance I guess you're using satellite because there was never a problem with the SD channels on DVB-T (Freeview). The eepg plugin supports Freesat and Sky's EPGs, but it has a memory leak and doesn't support Freeview HD, so instead I use a patch which various people have tweaked over time. I can't find a web download site for it or when it was last posted on this list, so if you're interested and others don't mind a 225K attachment I can post it here again. ___ 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG for BBC TV channels?
On Sun, 09 Mar 2014 15:20:31 +0100 Mario Schulz dr...@arcor.de wrote: Am 09.03.2014 14:38, schrieb Manuel Reimer: As this solution is a bit tricky and not very reliable, my question is, whether there is a better solution to get real EPG for those channels? Freesat uses a Huffman encoding for EGP data, which has not made its way into VDR core. a) Plugin EEPG has these tables (and covers some other EPGs as well) b) A Freesat patch extends VDR to just the Freesat code tables. The patch also covers Freeview HD (which uses the same encoding as Freesat, but with standard PIDs instead of Freesat's custom ones), which EEPG doesn't, unless it's been updated since I last used it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Minimum CPU requirement for xineliboutput + vdr-sxfe for HDTV
On Fri, 28 Feb 2014 12:49:12 +0100 Michal Novotny mic...@lightcomp.cz wrote: On 02/27/2014 09:29 PM, Stephan Loescher wrote: I know from my own VDR-systems, that a Intel Core2 Duo @ 1.86GHz or a Core i3 540 @ 3.07GHz has far enough power to run VDR and vdr-sxfe for displaying HDTV. My personal experience is that i5-2500K 3.30GHz plays HDTV well, but playback on E6500 2.93GHz is jerky. That's similar to my experience. I have a 3.1GHz i5-2400k and that can playback HD smoothly, but my 3.2GHz Phenom couldn't. That might have been my fault for not discovering the thread count option before using the i5 though :-). The deinterlacing method makes a big difference too, but xineliboutput makes that difficult to configure sensibly when you have a mixture of clients with and without VDPAU. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Logs from building VDR 2.1.3 with Clang 3.4.1
On Sat, 08 Feb 2014 13:51:10 +0100
Klaus Schmidinger klaus.schmidin...@tvdr.de wrote:
channels.c:45:119: warning: data argument not used by format
string [-Wformat-extra-args]
snprintf(buffer, sizeof(buffer), rid ? %s-%d-%d-%d-%d :
%s-%d-%d-%d, *cSource::ToString(source), nid, tid, sid, rid);
~ ^
This is explicitly checked with 'rid ? ...', so the warning is
unjustified (although the compiler probably has a hard time figuring
that out ;-).
The warning is justified, because if rid is 0 it's still there as an
argument, but just happens to have a value of 0. I think you can make
snprintf consume it without printing anything by adding %.d to the
second format string.
eit.c:223:43: warning: comparison of constant 176 with expression
of type 'SI::LinkageType' is always false
[-Wtautological-constant-out-of-range-compare]
if (ld-getLinkageType() == 0xB0) { // Premiere
World
^
I assume this is because the enum LinkageType doesn't contain 0xB0.
However, the actual value that comes from the SI data may well be
0xB0, so I'm now typecasting uint(ld-getLinkageType()).
If 0xB0 has a significant meaning wouldn't it be a good idea to add it
to the enum?
receiver.c:28:6: warning: indirection of non-volatile null pointer
will be deleted, not trap [-Wnull-dereference]
*(char *)0 = 0; // cause a segfault
^~
receiver.c:28:6: note: consider using __builtin_trap() or
qualifying pointer with 'volatile'
Can you suggest a different way of causing a segfault at this point?
You could add volatile as the warning suggests. Is there a good reason
not to use abort() instead?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Logs from building VDR 2.1.3 with Clang 3.4.1
On Sat, 08 Feb 2014 15:17:09 +0100
Klaus Schmidinger klaus.schmidin...@tvdr.de wrote:
On 08.02.2014 14:34, Tony Houghton wrote:
The warning is justified, because if rid is 0 it's still there as an
argument, but just happens to have a value of 0. I think you can make
snprintf consume it without printing anything by adding %.d to the
second format string.
I'm afraid not.
If I run
#include stdio.h
int main(void)
{
for (int n = 0; n 2; n++)
printf(n ? '%d-%d'\n : '%d%.d'\n, 1, 2);
return 0;
}
I get
'12'
'1-2'
But maybe there *is* such a format character, it just isn't %.d.
You're right, it looks like it has to be %.s, it doesn't work with %.d.
If you used %.s you'd probably just get a type mismatch warning instead
:-(. There's nothing wrong with the way you wrote it, but I like to
enable all possible warnings and eliminate them. In this case I think
I'd just print the rid even if it's 0.
Can you suggest a different way of causing a segfault at this point?
You could add volatile as the warning suggests. Is there a good reason
not to use abort() instead?
The idea behind this was to allow for easy backtracking in such a case.
I believe abort() wouldn't allow this, would it?
abort() does usually generate a useful core dump/stack backtrace IME.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Analyse .ts files
On 28 Dec 2013 19:13:59 +0100 cedric.dew...@telfort.nl cedric.dew...@telfort.nl wrote: I am planning to let VDR record shows in encrypted form. After the show has been captured, I would like to launch a low-priority task to decrypt the show. This means I will be fumbling a lot with .ts files. A lot of the time I will do it wrong. Is there a good tool to analyse .ts files Try dvbsnoop. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDPAU deinterlacing
Last night I tried to watch my recording of the final I.T. Crowd, but it was unwatchable because of the interlacing. However, other programmes look OK. Whatever I put for video.output.vdpau_hd_deinterlace_method and video.output.vdpau_sd_deinterlace_method in ~/.xine/config_xineliboutput it gets replaced with bob. The OSD doesn't have any options for VDPAU and none of the options it does have seem to make any difference. I recorded it from the 4Seven channel because I forgot about the first showing on C4HD, and it seems only this channel is affected. Maybe they haven't set deinterlacing flags correctly? It does seem to be an issue of interlacing being disabled when it should be enabled, because my recording played correctly in mplayer with deinterlacing enabled. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR jumps to old position after ff/rew
This problem still exists with vdr-sxfe and HD recordings. On Tue, 27 Aug 2013 11:28:24 -0700 VDR User user@gmail.com wrote: I believe that's a problem with the video decoder. I had the same problem using vdpau with vdr-xine long ago but it was quickly fixed. When I started testing vdr-softhddevice, the problem re-appeared. You can enable CONFIG += -DH264_EOS_TRICKSPEED in vdr-softhddevice/Makefile and it should work, assuming you're using vdr-softhddevice are using a recent git of it. On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg in...@nafets.dewrote: Hi all, I detected a strange behaviour in VDR 2.0.2: When I replay a recording and press right for fast forwarding and after some time press up to continue playing at this position vdr jumps back to the position where I started the forwarding. I would expect it to continue replay at the position where I forwarded to. Is this a known bug or do I have to press other keys or is there a setting to change it? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On Tue, 20 Aug 2013 10:12:25 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I wouldn't like to add a dependency to libudev. Why not? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDPAU for AMD
Anybody seen this? http://www.phoronix.com/scan.php?page=articleitem=amd_opensource_uvdnum=1 I think it's great news, at last there will be decent hardware acceleration for AMD graphics, on a fully open source stack, and without front-ends needing to use a new API. I know there was already Intel and VAAPI, but that hasn't caught on as well as VDPAU for some reason. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which epg for Sky UK
On Sun, 14 Apr 2013 10:05:54 +0200 Dimitar Petrovski dime...@gmail.com wrote: Hi, I maintain the eepg plugin, if you send me a stack trace, or add it as an issue here: http://projects.vdr-developer.org/projects/plg-eepg I will look into it. I'm using the eepg plugin for a very long time without any problem. For the memory leak, I have not I have not reproduced it in my usage of vdr, so if someone can provide me with the steps to reproduce it, which channel it happens on and so on I will try to fix it. I haven't associated the leak with any channel. I don't use VDR for live viewing very much, mainly for recording and playback. The memory seems to leak even when I'm not actively using VDR at all. I thought it must be caused by harvesting the EIT in the background. I think I tried using valgrind once, but it completely failed to notice the leak for some reason (perhaps valgrind doesn't apply to plugins?). VDR also used to spam my syslog with messages including the names of programmes, but it doesn't seem to be doing that any more. I think it was caused by something slightly amiss with Freeview's EPG that VDR thought it should warn about. This could be related to the leak, but I haven't used EEPG for a while. The other reason for me to use the patch is for Freeview HD's EIT. The encoding is exactly the same as Freesat's but I think the difference is that it still uses standard PIDs instead of non-standard ones. So EEPG would have to detect the encoding by using the flag bytes at the start of the string instead of by the PID they're from. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which epg for Sky UK
On Sat, 13 Apr 2013 22:35:39 +0200 dplu (free) d...@free.fr wrote: You can use eepg plugin who do the same job, works perfectly with vdr 2.0.0 @+ Le samedi 13 avril 2013 20:52:52 Scott Waye a écrit : Hi, I used to use freesat diff patch to get the 10 day schedule from UK Freesat (BSkyB 28.2E), but seems its not been supported much for a while so I wonder what others are using? Somebody updated the patch a few months ago with complete tables embedded in the code instead of loaded as separate files. Has eepg been updated to support Freeview HD and fix the memory leak? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which epg for Sky UK
On Sat, 13 Apr 2013 23:06:58 +0200 dplu (free) d...@free.fr wrote: Le samedi 13 avril 2013 21:48:44 Tony Houghton a écrit : Has eepg been updated to support Freeview HD and fix the memory leak? Good question, eepg create it's own file on conf directory , not seen memory leak but did not spend my life on Freesat channels I report it works even for channels like ITV HD, Channel 4 HD or BBC HD on 28.2E, it is more simple than patching vdr itself (even with internal huffman coded tables) Yes, it worked well enough apart from the problems I mentioned above. But the original maintainer hasn't commented on those and apparently the code isn't in a very good state for someone else to take over. Someone raised the possibility of rewriting the patch as a plugin, which I would like, but I don't know how to write VDR plugins. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Audio problem on Channel 4 HD on Freeview
The last two times I looked at Channel 4 HD on Freeview (DVB-T2) there was a strange problem with the audio. All the ambient sounds and background music were there but voices were very muffled. One time was a film and the other was a US drama series (Revenge). The same channel on Freesat (DVB-S2) was OK. This was on a remote client using xineliboutput + vdr-sxfe with analogue stereo audio. I just tried it on my main TV (also using vdr-sxfe but connecting to VDR on localhost) with HDMI audio, and the sound was normal on that, but it was a British cookery show. I don't know yet whether the difference was because of the type of programme or the respective PC's audio settings. I tried changing the stereo mix settings in VDR's xineliboutput plugin config, but one setting didn't do anything and the other turned it into a loud, harsh noise. Is this just the wrong audio stream being selected (I didn't think of trying to find an alternative stream at the time) or the player discarding channels instead of downmixing into stereo? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Ouya
Reading the Allwinner A10 thread made me think. Surely Ouya has great potential as a cheap, low power media client. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] in-kernel lirc and devinput
On Sat, 20 Oct 2012 14:10:53 +0300 Jouni Karvo jouni.ka...@iki.fi wrote: 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 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 bundle from eBay. It's certainly an improvement on the Hauppauge, but it has one key that doesn't work, an Enter key near the bottom (not the main OK key). I tested it with inputlirc and lirc and it produced the same codes in both. As inputlirc is simpler and seemed to have a better default auto-repeat delay I stuck with that. My inputlirc config is: EVENTS= OPTIONS='-g -n Media*' ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] in-kernel lirc and devinput
On Wed, 17 Oct 2012 21:21:41 +0300 Jouni Karvo jouni.ka...@iki.fi wrote: 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? 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFE: Make VDR more friendly when using combinations of DVB-S, DVB-T and DVB-C
On Sun, 17 Jun 2012 00:26:22 -0700 VDR User user@gmail.com wrote: Why not just patch VDR so it cycles through channels that use the same channel number. No bothering with sql databases dependency, no altering the real channel numbers, no real pain that I can think of. For example, say you have 3 different sources using the same channel number: channel 100, dvb-s channel 100, dvb-t channel 100, dvb-c You tune channel 100 from your remote, it tunes 100 dvb-s. Press 100 again and it tunes 100 dvb-t. And again, 100 dvb-c. And again, loop back to 100 dvb-s. Also, instead of having to enter the channel number to cycle through them, maybe just use different keys (skip +/-, ffw/rew, some other keys) to cycle. If there's only one of that channel number, the cycle keys don't do anything. The trouble with that idea is that it doesn't make it easy to work out which source you've selected, especially via vdradmin, unless that gets patched too. I use DVB-T and DVB-S and I select DVB-S where possible. The reception is more reliable, not being vulnerable to breaking up every time someone rides past on a motor scooter :-/. I do this manually, so it's important that I can tell which is which. The official LCNs (published in most listings magazines) for UK's DVB-T start at 1 and at 101 for DVB-S, so it's quite easy to keep them separate; I only have to renumber a few DVB-T radio stations to avoid clashes. This depends on external tools/scripts when scanning though. I think having VDR (optionally) show something like (T)/(S) next to the names is the best idea, but I also like the idea that it somehow understands that they can be considered as identical. Further, there are several regional variants of the main channels available on DVB-S, so it would be handy if it could prompt something like, It isn't possible to record BBC 1 South and BBC 2 simultaneously, but you can record the same programme from BBC 1 London instead. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Wed, 09 May 2012 12:14:48 +0100 Dominic Evans oldma...@gmail.com wrote: On 09/05/12 00:54, Tony Houghton wrote: I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids. I did fix a couple of memory leaks in my own local build of eepg, but I still find issues with it killing off my tuners after extended use, so I'm still not using it. Tbh, it would probably be better if someone coded it from scratch. Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Wed, 09 May 2012 16:31:23 +0100 Dominic Evans oldma...@gmail.com wrote: On 09/05/12 14:32, Tony Houghton wrote: On Wed, 09 May 2012 12:14:48 +0100 Dominic Evansoldma...@gmail.com wrote: [Problems with eepg] Tbh, it would probably be better if someone coded it from scratch. Or rework the alternative patch as a plugin. The patch seems quite stable to me. But it only supports Freesat and Freeview, not Sky and whatever else eepg supports. A smaller amount of work might be just to extend the patch to add a setup option to VDR's menus to enable/disable it (and have it disabled by default). The it could potentially be added to the standard patchlist for debian/ubuntu/yavdr. That sounds like a good idea. Tobias, would you be willing to add this patch if enabling it is made optional? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Wed, 09 May 2012 21:49:04 +0200 Tobi listacco...@e-tobi.net wrote: On 09.05.2012 18:16, Tony Houghton wrote: That sounds like a good idea. Tobias, would you be willing to add this patch if enabling it is made optional? Not if this can be done with a plugin as well. Where can I find the most recent version of the patch? This is the latest version which Mario Schulz sent me. It has the Huffman tables built in to the code now instead of as separate files. vdr.patch.gz Description: GNU Zip compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Tue, 08 May 2012 20:29:13 +0200 Tobi listacco...@e-tobi.net wrote: On 08.05.2012 18:34, Marx wrote I didn't know and that's why his repository isn't updated. In fact I use lately Debian's version (and I was quite suprised that so new version is available in Debian). Hovewer number of available plugins in Debian is pretty low. Do you know if he plans to migrate more of them to Debian? Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon. I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Freeview HD support
Freeview HD's EPG uses the same encoding as Freesat, but for some reason the EEPG plugin doesn't recognise it; it probably only uses the extended decoder when it's using Freesat's non-dtandard PIDs. EEPG's code is a bit tortuous, and it has a memory leak, so I decided to look again at the Freesat patch from http://www.rst38.org.uk/vdr/. It needed a bit of updating for recent versions of VDR, and I also updated the tables with data from the EEPG plugin. And it works nicely :-). I haven't been using it long, but it looks like it isn't leaking, and all the text in the EPG looks correct. I've uploaded it to http://www.realh.co.uk/vdr_freesat_freeviewhd.patch.gz. If you use Debian or Ubuntu you can add it to the source package with quilt import. But also add this line to debian/vdr.install (I got errors after trying to add it to the patch): freesat.t* var/lib/vdr/ If not using debs you'll have to copy the freesat.t1 and .t2 files there manually, or redefine FREESAT_DATA_DIRECTORY in libsi/freesat.c if you want them to live somewhere else. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview HD support
On Tue, 3 Apr 2012 17:33:49 +0100 Dominic Evans oldma...@gmail.com wrote: On 3 April 2012 16:23, Tony Houghton h...@realh.co.uk wrote: Also, I noticed that (like the EEPG plugin) Dominic's patch only looks for Freesat EIT data on PID 3842 (BAT SDT data is on PID 3841). This is where the EPG data can be found on the majority of the transponders, broadcast at a symbol rate of 22.0 MSymb/s. However, on the Arqiva transponder (11.427 GHz [1]) the data is instead present on PID 3002 (BAT SDT) and PID 3003 (EIT), and is transmitted at the much faster symbol rate of 27.5 MSymb/s. This should allow a full EPG to be retrieved far more quickly. RdioCaroline (one of the radio channels) is a channel you can tune your receiver to in order to lock on to this transponder. Thanks for that info. I knew there was a transponder where the EIT was broadcast at a much faster rate (I've heard you can get a complete week's EPG in ~30 seconds instead of the normal ~30 minutes) but I didn't realise it was on yet another pid. Back on the subject of Freeview HD, do you happen to know which part of the SI refers to the Freeview HD channel/transport? It doesn't appear to be listed in the standard NIT, although once you tune to that channel everything appears to be normal, other than the Huffman-encoded EIT and that even its own NIT doesn't refer to itself AFAICT. Ideally the patch could be updated to watch for both EIT PIDs, and (even more ideally) the VDR EPG idle scan code could be patched to immediately jump to Arqiva on S28.2E and retrieve the EPG rather than laboriously cycling through all the transponders. You don't have to cycle through all transponders for Freesat anyway, unless you want pids for the video, audio etc streams, because the SDT and EIT are of the other channel variety. You can do a complete channel scan (apart from getting pids) on any one Freesat transponder in a few seconds. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Recording two programmes with identical details
Say I tried to record the same programme twice, once from DVB-T and once from DVB-S, can VDR manage that? As they have different ids they should appear as unrelated to one part of VDR, but as they have the same titles and times it might want to make the same filenames for both of them and clash. Or is that what the last digit just before the .rec part of the directory name is for? How would I be able to tell which is which in the OSD etc? Would they be ordered by adapter number? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Memory leak (was Re: Channel 4 HD on Freesat)
On Tue, 13 Mar 2012 20:06:25 +0100 Mario Schulz dr...@arcor.de wrote: Am 13.03.2012 17:52, schrieb Tony Houghton: memory leak I just met hepi, he also is a Doctor Who fan and is tuned to Astra2 as I am. He complained about the bad status of EEPG, restarting his server every three days or so due to a memory leak within that plugin. I now also believe the leak is in the eepg plugin. I was probably still running it when I thought I was testing without a few months ago, because I didn't realise the debian init script/loader now automatically loads all installed plugins, not just the ones in order.conf. As this is a 'must have' if you are on Freesat, it might be closely related, even if you feel it is not... More important still with Freeview HD I think, because that doesn't even have EIT p/f in plain text like Freesat does. I personally do not care because I have the receiver off most of the time. How would you analyze or debug a memory leak in a running environment: - which thread/plugin is the root cause? - which datastructure sees the growth? - which allocs are not bracketed by a proper de-alloc? Debian also includes a script to run vdr in valgrind but it didn't find the leak even when I added the --show-reachable option. Perhaps I need to check the fork-related options. I haven't tried static analysis of the source code so far because C++ isn't my forte. Are any of eepg's developers available to check into this? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EEPG (was Re: Channel 4 HD on Freesat)
On Tue, 13 Mar 2012 09:55:06 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 12.03.2012 23:01, Tony Houghton wrote: ... I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind. Which version of VDR are you using? Are you sure this is caused by the core VDR code, or could this be one of the plugins or patches you are using (if any)? I'm asking because I don't see an ever increasing memory footprint on my VDR. No, I haven't seen anybody else complain about this either. It's been happening to me for quite a long time, for several versions. I use the Debian packages. I thought it could be the eepg plugin but disabling that didn't seem to fix the leak. I also use xineliboutput and remote plugins, but I've been using those for years, before the leak started. At one point it stopped leaking and I realised I'd messed up my channels.conf so either all the DVB-T or all the DVB-S channels were broken and the leak came back when I fixed that. I think I tried reproducing similar conditions but for some reason I didn't make an effort to record or remember the results! I should repeat that and make notes, but it takes about a day on each run before I can be reasonably sure whether it's leaking or not. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Memory leak (was Re: Channel 4 HD on Freesat)
On Tue, 13 Mar 2012 16:11:44 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: Can you give me an estimate of the rate at which memory is consumed? Maybe you could have a shell running the command top -b -d 600 | grep -w vdr At the moment: 25956 vdr 20 0 520m 213m 5136 S 0.7 11.3 28:27.27 vdr After a restart: 24585 vdr 20 0 257m 43m 5316 S 0.0 2.3 0:00.88 vdr It starts to have a noticeable impact on the box's general performance when %MEM reaches 50% IME. I'll run top for longer like you suggest, then try all plugins disabled and with DVB-T and DVB-S lines removed from channels.conf in turn. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel 4 HD on Freesat
On Mon, 12 Mar 2012 07:43:40 +0100 Mario Schulz dr...@arcor.de wrote: Am 12.03.2012 01:07, schrieb Tony Houghton: Are some DVB-S2 cards incapable of 8PSK? Mine's a TBS 6920. Tried yr 2nd variant: Channel 4 HD;Freesat:11126:VC23M5O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0 ... reception tested ok here. That's strange. I confirmed my card's OK after all, I managed to record a bit of the channel with hdvb. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel 4 HD on Freesat
On Sun, 11 Mar 2012 23:41:06 + Tony Houghton h...@realh.co.uk wrote: I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays silent with the picture frozen on the previous channel, or No signal. Any ideas? The plot thickens. I've done some more tests. I used hdvb to record samples of BBC 1 HD, ITV1 HD and Channel 4 HD. MPlayer can play all of them. It tells me BBC is 1440x1088, the others are 1920x1088. All appear to be interlaced. BBC appears fine on my HTPC/TV, with sxfe configured for vdpau with bob deinterlacing. On a remote PC running sxfe (onboard Intel graphics, so no vdpau) I could see interlacing artifacts, probably because I configured deinterlacing off in VDR's OSD (see below). ITV plays too slowly in sxfe on the HTPC. The graphics card is only an 8200 so I tried reconfiguring .xine/config_xineliboutput to use xv and turned off deinterlacing (see above). It didn't seem to make any difference, but the CPU is a 2.4GHz Athlon x2, so it should be fast enough. It was with MPlayer, and so was the other PC (a somewhat faster Core i5 2500k) with vdr-sxfe. Channel 4 won't play at all in sxfe on either PC, but does in MPlayer. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EEPG (was Re: Channel 4 HD on Freesat)
On Mon, 12 Mar 2012 22:24:16 +0100 Lucian Muresan luci...@users.sourceforge.net wrote: Please forgive me for going off-topic, are you actually successfully using the EEPG plugin without segfaults? If so, which version, what sources? I dropped using it because it crashed my VDR every now and then, I haven't noticed that problem. I do have to restart VDR every few days anyway, because it has a memory leak. Disabling eepg didn't fix that IIRC, and the leak hides from valgrind. I use 'apt-get source' to fetch the eepg plugin from the yavdr PPA: deb-src http://ppa.launchpad.net/yavdr/unstable-vdr/ubuntu oneiric main The binary package is incompatible with Debian unstable, but that source always compiles OK for me when a vdr upgrade makes it necessary. The current version is 0.0.5.git20110719-0yavdr5~0.1. Do you British folks, or more generally, Freesat viewers know of any working alternatives to the EEPG plugin for the channels on S28.2E? I used to use the patch from here: http://www.rst38.org.uk/vdr/. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Channel 4 HD on Freesat
I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays silent with the picture frozen on the previous channel, or No signal. Any ideas? This is my channels.conf entry: Channel 4 HD;Freesat:11126:VC23M2O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0 Not much going on in syslog: Mar 11 23:33:37 htpc vdr: [2449] switching to channel 126 Mar 11 23:33:37 htpc vdr: [2449] setstatus 0 Mar 11 23:33:37 htpc vdr: [3031] TS buffer on device 2 thread ended (pid=2449, tid=3031) Mar 11 23:33:37 htpc vdr: [3030] buffer stats: 63732 (3%) used Mar 11 23:33:37 htpc vdr: [3030] receiver on device 2 thread ended (pid=2449, tid=3030) Mar 11 23:33:37 htpc vdr: [2537] setstatus 0 Mar 11 23:33:37 htpc vdr: [2537] setstatus 1 Mar 11 23:33:37 htpc vdr: [2537] Filter Pid:0,Tid:0 added. Mar 11 23:33:37 htpc vdr: [3535] receiver on device 2 thread started (pid=2449, tid=3535) Mar 11 23:33:37 htpc vdr: [3536] TS buffer on device 2 thread started (pid=2449, tid=3536) Mar 11 23:33:38 htpc vdr: [2537] PMT scan idle Mar 11 23:33:38 htpc vdr: [2537] EEPG: FreeView Extended EPG detected on pid f02. Mar 11 23:33:38 htpc vdr: [2537] Loading table 1 Filename /var/lib/vdr/plugins/eepg/freesat.t1 Mar 11 23:33:38 htpc vdr: [2537] Loading table 2 Filename /var/lib/vdr/plugins/eepg/freesat.t2 Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:4e,Mask:fe added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:50,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:60,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:39,Tid:50,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:39,Tid:60,Mask:f0 added. Mar 11 23:33:38 htpc vdr: [2537] Filter Pid:f02,Tid:b0 added. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel 4 HD on Freesat
On Sun, 11 Mar 2012 23:41:06 + Tony Houghton h...@realh.co.uk wrote: I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays silent with the picture frozen on the previous channel, or No signal. Any ideas? This is my channels.conf entry: Channel 4 HD;Freesat:11126:VC23M2O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0 I realised it has a different modulation (8PSK) from the working channels so I changed the parameters to VC23M5O0S1, but it still doesn't work :-(. Are some DVB-S2 cards incapable of 8PSK? Mine's a TBS 6920. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Local frontend - using XBMC strm vs vdr-sxfe
On Fri, 9 Mar 2012 09:59:51 + Dominic Evans oldma...@gmail.com wrote: Running vdr-sxfe as a local frontend using a pipe _should_ be as fast (if not faster) than using XBMC over an http://localhost streamdev connection. However, I seem to find the opposite to be the case. vdr-sxfe still struggles with HD content, has pops and clicks in the audio, crashes out every now again and generally has inferior playback. On my main frontend I have VDR running full time in the background with no local frontend running. Then I have a bare-bones X11 configured with a simple .xinitrc that flips between running vdr-sxfe and xbmc (as I prefer it for watching DVDs etc.). For both frontends I am using VDPAU. I have to use vdr-sxfe to interact with the menus, auto skip adverts in recordings, do cutting, etc. But I'm increasingly finding myself using XBMC and just a directory full of .strm files that point at streamdev TS links, when I want to watch a live HD broadcast. IME sxfe works better watching live than a recording, but I'm not sure whether it affects how often the audio glitches. Such things in vdr-sxfe seem to come and go at random. Last time I watched an HD recording the picture regularly jerked, like you get when watching 24fps video very crudely converted to 25fps by repeating a frame every second. But live TV seems quite smooth. The difference between vdr-sxfe and XBMC you're experiencing could be due to differences in the deinterlacing setting. You didn't say what your graphics card is, but the sort of low-power fanless card most of us like to have in an HTPC can't manage the higher quality options. The default for libxine is temporal, which my lowly 8200 is too slow for in HD (but OK in SD), so I had to use this setting: video.output.vdpau_hd_deinterlace_method:bob I was amazed at how good it looks, although I've only tried it at 720p output so far, not at 1080p. I thought I was going to have to add at least a GT210 PCI-E card, but it looks like that's going to be unnecessary. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Local frontend - using XBMC strm vs vdr-sxfe
On Fri, 9 Mar 2012 14:15:06 + Dominic Evans oldma...@gmail.com wrote: On 9 March 2012 13:42, Tony Houghton h...@realh.co.uk wrote: video.output.vdpau_hd_deinterlace_method:bob I was amazed at how good it looks, although I've only tried it at 720p output so far, not at 1080p. I thought I was going to have to add at least a GT210 PCI-E card, but it looks like that's going to be unnecessary. I actually currently have deinterlacing disabled on both xineliboutput and XBMC. AIUI interlaced fields are encoded as a pair in one field, so for most video players disabled, ignoring the interlacing flags and treating it as as normal frame is the same as weave. You usually get quite noticeable combing artifacts with that. Bob is more or less an alternative way of doing next to nothing; it displays each field in turn without any attempt to combine them. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Fri, 02 Mar 2012 08:29:00 +0100 Gerald Dachs v...@dachsweb.de wrote: Am 2012-03-02 00:18, schrieb Tony Houghton: Going off on a tangent, there's been some discussion about Pause and rewind live TV. That could be implemented fairly easily in clients with a big RAM buffer, without adding any complexity to the server. Big RAM buffer means long breaks between channel changes. Not necessarily, because you don't have to wait for the buffer to fill before playing the content. I meant to play the stream as soon as possible, but also keep the data in a buffer for a short time so the viewer can rewind. It wouldn't need to be for long, not even more than a minute, because what I had in mind is when you miss what someone said and rewind to hear it again. However, if the user pauses instead the buffer should be able to grow as necessary. That gets complicated if the pause ends up being longer than the available RAM. Possible strategies are: Drop the buffer (LIFO or FIFO?) and miss some of the programme. Not good. Allow the client to write the buffer to disc. Partly duplicates server functionality but I think it's probably the best plan. Signal the server to start recording. But then the client has to be able to match up its buffer with what the server has recorded after the buffer filled and let the server know when the temp recording is no longer needed. Complicated. Have the server record everything it plays and not bother with buffering in the client. I don't think most people want VDR to work that way because of extra load on the hard drive. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Fri, 2 Mar 2012 10:30:37 +0100 fnu v...@auktion.hostingkunde.de wrote: about Pause and rewind live TV. What is live TV there, as it is already recorded ... ? Only users which didn't got into VDR and epgsearch timers do call for this live buffer function. They hope for a kind of security, which this function doesn't really provide. I disagree, my sister's got a Humax which can pause and rewind, it's really useful. She's even willing to have inferior picture quality (older MPEG decoder, analogue SCART etc vs modern TV's inbuilt decoder) just to be able to pause and rewind. VDR can already pause, but what if there's a sudden distraction and you miss something before you can press the pause button? Then rewind is very nice. You want to have a feeling how it feels, if a live buffer is the underlying central function in a PVR solution, just go and test MythTV. Do you mean because of slow channel switching? A buffer doesn't have to cause that, see my other post. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Thu, 01 Mar 2012 22:12:19 +0100 Manuel Reimer manuel.rei...@gmx.de wrote: Tony Houghton wrote: I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. It just has to deliver the data. The OSD itself is created by the client. That's how most other TV software works, but if you count VDR itself as server and vdr-sxfe as client then my understanding is that the server generates the OSD and the client just renders the pixmap it gets from the server. That wouldn't necessarily have to change if and when VDR goes fully client-server, but if I was implementing something from scratch I'd prefer to do the rendering on the client. It would reduce server load and network traffic, and be more logical to my mind. And free up more of Klaus' time to concentrate on core functionality while other people can add bling :-). Going off on a tangent, there's been some discussion about Pause and rewind live TV. That could be implemented fairly easily in clients with a big RAM buffer, without adding any complexity to the server. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer manuel.rei...@gmx.de wrote: Klaus Schmidinger wrote: Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). I'll see to make client/server a priority after that. What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other built-in plugins. I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and xine-ui not fitting together
On Fri, 03 Feb 2012 22:08:59 +0100 Tobi listacco...@e-tobi.net wrote: On 03.02.2012 16:22, Manfred Schmidt-Voigt wrote: working xineplugin (xineplug_inp_xvdr.so) for the xine-ui. xine-ui now ist based on libxine2 but the libxine1-xvdr plugin is based on libxine1 (as the name allready states). Are there any plans to create a debian package of the plugin which fits also to libxine2? I'll upload a new package tonight. Thanks for your work on these packages. VDPAU support at last! I've been so reluctant to compile all this stuff myself, maintaining it on at least 3 PCs and making sure it doesn't clash with other ffmpeg-based packages etc (or worse, switch to mythtv) that I hadn't been enjoying HD until now. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] playback problems with recordings with vdr-1.7.20 and newer
On Fri, 27 Jan 2012 17:38:25 +0100 Oliver Endriss o.endr...@gmx.de wrote: On Friday 27 January 2012 15:30:18 Andreas Albert wrote: Then i got an other problem. When watching a recording, and i fastforward of rewind the program, i get to a situation that the timecounter get's stuck to the frame i start from. The film moves, but when i hit play, i end up back to the frame from where i started to rewind/fastforwad. [Snip] | + The full-featured DVB cards need an improved firmware in order to return |proper STC values in trick modes. | ... You can download an updated firmware from http://www.escape-edv.de/endriss/firmware/ I've noticed a similar problem sometimes, but not always. My cards are a TBS 6920, which uses dvb-fe-cx24116.fw, and a Hauppauge Nova-T which uses dvb-fe-tda10045.fw. Are there firmware fixes for these? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] howto ignore lines in channels.conf
On Mon, 16 Jan 2012 11:51:26 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 16.01.2012 01:45, Tony Houghton wrote: VDR can already do that. Before each numbered group add a line :@1 , :@10 , :@20 etc. Exclude the quotes, but ISTR there was some problem if I didn't include a trailing space. There's no, need for a trailing space. I know it isn't necessary, and I can't remember exactly why I use them, but one of the existing programs (either VDR itself, or scan) used to append spaces. Making my own tool do the same made it easier to detect whether the file needed updating or something. I use this to make my channels numbered the same way as Freeview and Freesat, so I'd prefer it if channels lines had an LCN field instead of putting the numbers on separate lines. An LCN field would only make sense if you have only channels from a single broadcaster in your channels.conf. As soon as there are several broadcasters, the numbers would most likely not be unique any more, and therefore useless. Yes, you would need an additional field for the broadcaster or bouquet or something and provide a way for the user to select which set of channels they're viewing. Probably not easy or very practical to add to VDR at this point. Fortunately there are few clashes between Freeview and Freesat, and all I have to do is renumber a few radio channels which I virtually never use. I think you can also use a : followed by a string without @ to add comments, which are shown in the EPG. These are channel group separators, which you can easily navigate through with the Left and Right keys in live mode. The texts are *not* shown in the EPG, though. I shouldn't have called it EPG. I really meant the channel list view. I'm sure when I used these group labels they were shown in VDR's OSD. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Betr: Re: howto ignore lines in channels.conf
On Sun, 15 Jan 2012 23:18:40 +0100 cedric.dew...@telfort.nl wrote: There is one bit of information that I would like to add to channels.conf, and that's the channel number. This information cannot be added the README, and other files, as this is information that only I use. My channel.conf now looks like this (from memory, I'm not in front of the machine right now) #1 Nederland 1: *a whole lot of numbers* #2 Nederland 2 *a whole lot of numbers* This reminds me, it's now not possible to have a list of channels with gaps in it. I would like it if I can create a list like this: #1..5 My favorite channels 1 Discovery channel 2 MTV 3 Some other channel 4 Comedy channel 5 Some other channel #10..15 channels of my wife (just married this friday :-) ) 10 RTL 4 11 RTL 8 #20 channels we both like ;-) 20 animal planet 21 discovery channel (identical to channel 1) 22 ... VDR can already do that. Before each numbered group add a line :@1 , :@10 , :@20 etc. Exclude the quites, but ISTR there was some problem if I didn't include a trailing space. I use this to make my channels numbered the same way as Freeview and Freesat, so I'd prefer it if channels lines had an LCN field instead of putting the numbers on separate lines. I think you can also use a : followed by a string without @ to add comments, which are shown in the EPG. So I'm surprised everyon'e saying you can't have comments in channels.conf. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sxfe and vsync
On Mon, 26 Dec 2011 10:43:42 +0100 gimli gi...@dark-green.com wrote: Two things to mention about vaapi : 1.) Use xf86-video-intel-2.15.0 Do you mean at least 2.15, or are there problems with later versions like 2.17? 2.) Forget sxfe in combination with vaapi. sxfe plays bad tricks with the stream and is not able to do a clean reinitialize of the output when the stream is changing. Another issue is compositing. This is the future of window management and some people like (OK, tolerate) GNOME 3 and even Unity, so saying, Don't use compositing isn't good enough long term IMO. On my Ion 2-based nettop I can watch video in GNOME 3 OK, but I'm not sure vsync works with it OK on my NVidia 8200-based HTPC. I don't mind using xfce4 on that for now, because I don't use it for much else. But I've got two other machines with Intel graphics on which I'd rather use GNOME 3 than xfce4 and still be able to watch video without tearing, and I haven't managed that so far :-(. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sxfe and vsync
On Thu, 03 Nov 2011 22:00:10 +0200 prelude prel...@kapsi.fi wrote: This maybe help: http://lowbyte.de/vga-sync-fields/vga-sync-fields/README No, that's so you can slightly adjust the rate at which the display is refreshed to match the rate at which you're receiving the stream. That's a non-issue if you can't sync your frame changes to the refresh! On 11/01/2011 07:01 PM, Tony Houghton wrote: When using NVidia graphics cards and the proprietary driver I find vdr-sxfe looks quite smooth even with a monitor that only supports 60Hz. I think it's been syncing to the vertical blank automagically. But with other graphics cards I get a lot of tearing which is marring my viewing pleasure. This is happening both with Intel Sandy Bridge (normal monitor) and a Radeon 5450 with fglrx connected to a TV. The free ati driver isn't a practical option on that because the HDMI audio doesn't work with it. I'm using the xv output in each case. Is there a way to make vdr-sxfe sync to the vertical blank with these cards/drivers? ___ 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] sxfe and vsync
When using NVidia graphics cards and the proprietary driver I find vdr-sxfe looks quite smooth even with a monitor that only supports 60Hz. I think it's been syncing to the vertical blank automagically. But with other graphics cards I get a lot of tearing which is marring my viewing pleasure. This is happening both with Intel Sandy Bridge (normal monitor) and a Radeon 5450 with fglrx connected to a TV. The free ati driver isn't a practical option on that because the HDMI audio doesn't work with it. I'm using the xv output in each case. Is there a way to make vdr-sxfe sync to the vertical blank with these cards/drivers? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FreeviewHD compressed EPG
On Tue, 25 Oct 2011 14:39:46 +0100 (BST) Dominic Morris d...@suborbital.org.uk wrote: On Tue, 25 Oct 2011, Dominic Evans wrote: On 25 October 2011 14:27, Tony Houghton h...@realh.co.uk wrote: On Tue, 25 Oct 2011 13:54:36 +0100 (BST) Dominic Morris d...@suborbital.org.uk wrote: Complete tables are here: http://rst38.org.uk/vdr/freesat_tables_complete.zip Those are the ones with holes in aren't they? Stuart Morris said he had to port the tables from eepg. No, I believe EEPG took these exact tables from the same source(s) as Dom got them. Its just the freesat.diff hadn't been updated to contain the complete tables 'in-patch'. That's correct. The ones in the patch are those deduced through observation, there's an updated version of those here: http://rst38.org.uk/vdr/freesat_tables_20081027.zip Those files are completely legitimate. The complete tables were extracted from an OTA firmware upgrade and are complete. They may have dubious legality. Which are newer, complete or 20081027? I was using complete with the patch before I switched to eepg and I'm pretty sure I did notice holes very occasionally. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-sxfe and compositing
I'm having some problems with vdr-sxfe under GNOME3/mutter. If I start it with --fullscreen it doesn't go fullscreen properly; I can still see the gnome shell panel at the top of the screen and there's no vsync so I get tearing. If I toggle fullscreen off and on again by double-clicking it does cover up the panel correctly but I still get tearing. If I start it without --fullscreen and double click it works correctly without tearing. I would have thought it would be a good idea to have an output backend especially for compositors because AIUI compositing provides features like scaling and YUV-RGB conversion and it would probably be more efficient to work directly with the compositor instead of xv. Is there such a thing for xine? Or would it make sense to use opengl? I've just been watching a recording of Nasa's Greatest Missions from the Quest channel. It was quite jerky, but I think it may have been because the US source was badly converted to PAL; it was one big jerk every second and other programmes don't suffer from this, but I still think it's maybe more jerky than it was with GNOME 2. Could be my imagination. But after watching the NASA thing I noticed that vdr-sxfe had printed loads of copies of this message: [21326] [input_vdr] vdr_adjust_realtime_speed: assertion failed: this-is_trickspeed is true ! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wanted VDR xineliboutput client
On Mon, 17 Oct 2011 17:28:17 -0700 VDR User user@gmail.com wrote: On Mon, Oct 17, 2011 at 10:37 AM, Tony Houghton h...@realh.co.uk wrote: Is this client only with no DVB cards? You could use an Acer Revo, provided you're confident that you can get VDPAU working, because the Atom CPU is a bit weak for HD. An HP Microserver with an added graphics I'm a vdpau user and can say it's works just fine here. Did you compile the xine stack yourself? I find it's very picky, eg if I try to use a repository with a set of packages that allegedly support VDPAU, vdr-sxfe doesn't work at all, and there are also difficulties getting xine, mplayer and gstreamer to all coexist with ffmpeg. they're only about £130 with the cashback offer. Unfortunately I couldn't find a passively cooled VDPAU-capable card that would fit so I There are a few, here's on example: 1 slot passive cooled Zotac GT430 http://www.newegg.com/Product/Product.aspx?Item=N82E16814500221 Wouldn't fit. The Microserver only takes low profile cards and the x16 slot is also the one nearest the side of the case so there's no room for a double height backplane or thick heatsink like this: http://www.ebuyer.com/240886-asus-geforce-g210-silent-512mb-ddr2-dvi-vga-hdmi-out-directx-10-1-en210-silent-di-512md2-lp- An 8400GS might fit, but I wouldn't expect its VDPAU capabilities to be up to much. I currently use 8200 onboard graphics with mplayer VDPAU and it's rather jerky as if it's dropping frames just on 720p (with the TV at 1280x720 so no scaling is required). But that could be mplayer struggling to sync 24fps to 60Hz. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wanted VDR xineliboutput client
On Mon, 17 Oct 2011 17:28:17 -0700 VDR User user@gmail.com wrote: On Mon, Oct 17, 2011 at 10:37 AM, Tony Houghton h...@realh.co.uk wrote: Is this client only with no DVB cards? You could use an Acer Revo, provided you're confident that you can get VDPAU working, because the Atom CPU is a bit weak for HD. An HP Microserver with an added graphics I'm a vdpau user and can say it's works just fine here. Did you compile the xine stack yourself? I find it's very picky, eg if I try to use a repository with a set of packages that allegedly support VDPAU, vdr-sxfe doesn't work at all, and there are also difficulties getting xine, mplayer and gstreamer to all coexist with ffmpeg. they're only about £130 with the cashback offer. Unfortunately I couldn't find a passively cooled VDPAU-capable card that would fit so I There are a few, here's on example: 1 slot passive cooled Zotac GT430 http://www.newegg.com/Product/Product.aspx?Item=N82E16814500221 Wouldn't fit. The Microserver only takes low profile cards and the x16 slot is also the one nearest the side of the case so there's no room for a double height backplane or thick heatsink like this: http://www.ebuyer.com/240886-asus-geforce-g210-silent-512mb-ddr2-dvi-vga-hdmi-out-directx-10-1-en210-silent-di-512md2-lp- An 8400GS might fit, but I wouldn't expect its VDPAU capabilities to be up to much. I currently use 8200 onboard graphics with mplayer VDPAU and it's rather jerky as if it's dropping frames just on 720p (with the TV at 1280x720 so no scaling is required). But that could be mplayer struggling to sync 24fps to 60Hz. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wanted VDR xineliboutput client
On Sun, 16 Oct 2011 14:02:42 +0300 JJussi v...@jjussi.com wrote: Any suggestions for small, powerful, quiet, FullHD VDR client? So, I search machine what would act as VDR-client, using xineliboutput with FullHD resolution and machine would have DVI or HDMI connection + optical audio. Is this client only with no DVB cards? You could use an Acer Revo, provided you're confident that you can get VDPAU working, because the Atom CPU is a bit weak for HD. An HP Microserver with an added graphics card (and perhaps extra RAM too) is also worth considering, because they're only about £130 with the cashback offer. Unfortunately I couldn't find a passively cooled VDPAU-capable card that would fit so I had to use a Radeon 5450 [1], and nothing much supports VA-API yet :-(. I wish that would catch on. The HP's 1.3GHz AMD x2 CPU is better than any Atom and seems to be able to play 720p in software OK, but probably wouldn't be able to do any sort of advanced deinterlacing. And it has no onboard sound so you'd need an additional USB or low-profile PCI-E sound card too if you can't use HDMI audio. Of course remote control is needed too! ;-) Best to buy one separately. [1] You need one with either 2 separate low-profile backplates or be prepared to cut a double one in half because there's no spare slot to the left of the HP's PCI-e x16 slot. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T2 tuning
On Mon, 10 Oct 2011 17:31:14 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I'm not aware of any DVB-T2 specific code in VDR 1.7.x. For DVB-S2 there had to be a special flag and additional tuning parameters. Don't know how this is handled with DVB-T2. This may help: http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#dvbt2-params ETSI EN 300 468 still doesn't cover DVB-T2 (but it does cover S2) but by googling for DVB-T2 delivery descriptor I found this PDF: http://www.dtg.org.uk/dtg/t2docs/Layer%202%20signalling_Simon%20Waller_Sony.pdf It doesn't go into much detail, including what the identifier code is for that sort of descriptor, but maybe dvbsnoop is already aware of that? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
On Wed, 27 Jul 2011 09:16:17 +1000 Torgeir Veimo torg...@netenviron.com wrote: I find that the old grey hauppauge remote has the perfect arrow key / coloured key layout, but it doesn't have any programmable volume and channel keys. http://www.ixbt.com/monitor/images/hauppauge-mediamvp/du.jpg If anyone else noticed that support for that type of remote got broken sometime after 2.6.32, I'm pleased to report mine is working again since I upgraded to kernel 3.0. I've got a TBS 6920 too now, its remote can be seen in one of the pictures at http://www.tbsdtv.com/english/product/6920.html. It has separate volume and channel keys but not play, stop or record (did they not think people would use it for a PVR?!). Despite explicitly claiming Linux support for the card in general the remote doesn't work. The linuxtv wiki doesn't mention the remote. Does anyone know if support for this is being worked on? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
On Fri, 29 Jul 2011 10:04:35 -0700 VDR User user@gmail.com wrote: On Fri, Jul 29, 2011 at 7:45 AM, Tony Houghton h...@realh.co.uk wrote: http://www.ixbt.com/monitor/images/hauppauge-mediamvp/du.jpg If anyone else noticed that support for that type of remote got broken sometime after 2.6.32, I'm pleased to report mine is working again since I upgraded to kernel 3.0. I've got one of those that has worked fine in 2.6.32 up to 2.6.39.3... It's connected with a serial IR. Maybe support for your particular IR receiver broke, but that remote has been just fine. Mine is connected via the DVB card. It says saa7146 in /proc/bus/input/devices but ISTR it's actually the budget or budget_ci module that handles it. It used to require a patch a few years ago and I think the patch was for the key mappings. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VPS fallback patch
On Mon, 18 Jul 2011 12:53:45 +0100 Dave v...@pickles.me.uk wrote: However I wonder if the time is now right to reconsider? In the UK an accurate Now Next EIT is provided on DVB-T as part of the Freeview Plus (aka TV- Anytime) service, with the data being directly derived from the broadcasters' playout systems. I have been running vdr with this patch for two years and have never missed a recording due to incorrect information. It was really useful during the recent Wimbledon tournament when many programmes ran late due to live coverage of the tennis. Does the standard EIT now reflect the actual times? I was under the impression that the EIT still reflected the original schedule and the actual times were somewhere in the TVAnytime extensions. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] strcmp() segfaults if one (and only one) of the parameters is NULL ?
On Tue, 5 Jul 2011 15:40:14 +0200 sundararaj reel sundararaj.r...@googlemail.com wrote: strcmp() returns 0 if both are parameters NULL, but segfaults if one of the parameters is NULL. I think that's officially undefined behaviour. The easiest workaround (in the absence of something like glib which provides NULL-safe versions of some str functions) is to use strcmp(s1 ? s1 : , s2 ? s2 : ) but only if it doesn't matter that NULL compares equal to . ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT: s2api backwards compatible?
Is s2api backwards compatible ie can you use it on older, non DVB-S2, cards? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: s2api backwards compatible?
On Sun, 03 Jul 2011 20:53:00 +0200 Udo Richter udo_rich...@gmx.de wrote: Am 03.07.2011 19:55, schrieb Tony Houghton: Is s2api backwards compatible ie can you use it on older, non DVB-S2, cards? It is, in both ways: Any supported DVB card can always be accessed by s2api and by DVB v3 API. Functionality may be limited on DVB v3 API of course. S2api is part of any kernel = 2.6.28. Thanks, just what I needed to know. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD programme recording still broken
On Fri, 10 Jun 2011 21:41:05 +0200 Luboš Doležel lu...@dolezel.info wrote: On 10.6.2011 21:11, VDR User wrote: I've just read a post from another user who had this problem. Apparently his channels.conf contained wrong info and enabling 'update names pids' (or whatever it's called) fixed it. Wow, great, that fixed it! Thanks! I think, however, that this should be either noted somewhere or the VDR should handle the error more gracefully... Or it should read the pids from the PAT and PMT every time it changes channel instead of using channels.conf for that information. This would also fix the problem of having to scan twice at different times of day to pick up all the channels. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD programme recording still broken
On Fri, 10 Jun 2011 23:31:40 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 10.06.2011 23:27, Tony Houghton wrote: Or it should read the pids from the PAT and PMT every time it changes channel instead of using channels.conf for that information. This would also fix the problem of having to scan twice at different times of day to pick up all the channels. When you switch to a transponder VDR *does* read the PAT/PMT. But if the user's setup tells it *not* to do so, what's VDR supposed to do then? I didn't realise that was what that option did and mine was disabled. What's the default setting? I might have turned it off deliberately to try to stop VDR from updating channels.conf at some point in the past when I was using dvb-apps scan to generate channels.conf and VDR didn't quite recognise the format and created duplicate channels, crashing itself. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Sky UK Channels.conf - Channel Numbering Categories
On Thu, 5 May 2011 13:15:10 +0100 Dominic Evans oldma...@gmail.com wrote: I had been interested in generating a channels.conf that contained the channels grouped by the Sky UK genre categories, whilst also using the same channel numbering. OOI, how do you get the channel numbering? I know how to get the numbers for Freesat (and Freeview) and have written a scanner which can generate numbered channels.conf files in VDR format. Of more interest to me than Sky numbering is to get the regional variations right in Freesat. There are some extra fields in its LCN descriptors, but I don't know how to use them. I've had to hardwire certain mappings by name (eg BBC 1 South = 101 etc), but all the Channel 4 variants have the same name and my script has assigned 104 to a Northern Irish variant judging by the adverts. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Sky UK Channels.conf - Channel Numbering Categories
On Thu, 5 May 2011 16:08:09 +0100 Dominic Evans oldma...@gmail.com wrote: I'm not sure how important this is to people? I'm just as happy with BBC1 London at 101 as I am with BBC1 South. If I _really_ want regional news I can always switch to it by choice. I do prefer BBC's South Today to London's regional news. But the big advantage of BBC 1 London is that it's on the same transponder as BBC 2 England, Channel 5 and BBC THREE etc, so you can record/watch more than one at a time, whereas the other regions tend to be shared with other regions of the same channel. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How about a small UK/Ireland S28.2E VDR community forum?
On Thu, 05 May 2011 17:38:42 +0200 Henning Pingel henn...@henningpingel.de wrote: I was wondering if it would make sense to offer a place for VDR users using the sky_uk/freesat/S28.2E/freeview platforms to communicate with each other. The intention is that people can discuss their special needs like freesat EPG, red button stuff, channel lists, channel logos and all other things and test new inventions (like the red button extension) together. Being a frequent user of freesat channels myself and being a member of the developers behind the yaVDR distribution (www.yavdr.org), I would like to offer to you to open up an English language community forum on our yaVDR board located at forum.yavdr.com [1]. This board is currently mostly used by our development team for internal discussions, so there is not much to see there for external visitors yet. I'd be interested. But I wonder whether it would be appropriate to allow discussion of UK specifics in other software too eg mythtv. Ultimately VDR doesn't quite suit my needs due to its poor support for viewing across a network, while mythtv's setup tool always makes me give up in disgust. That's why I started boxstar, but it might be a very long time before it becomes usable in its own right. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Sat, 2 Apr 2011 12:33:58 +0300 (EEST) Rolf Ahrenberg rahre...@cc.hut.fi wrote: The RGYB color enumeration is defined in the video teletext standard and every TV/STB set implementing the teletext feature DOES use the mentioned color button order. I guess the teletext is used mainly in Europe, so there might be different conventions elsewhere, but the VDR is a STB for DVB standard that documents the teletext too. IMO, you really should switch the OSD button colors in skin plugins instead of patching the core VDR. There will be some glitches with learning the remotes, but these can be fixed with some extra documentation (Press 'Red/leftmost color' button). These remotes with wrong color button orders are really a small minority here mainly targeted to some odd mediacenters or PS3 - at least here in the northern Europe. It isn't true that only very obscure and trashy remotes have the buttons in the wrong order. I've got a Sony TV where the colours are arranged in a sort of cross layout with green above blue and red and yellow at the sides. It's a good quality remote that I think was used with a number of different models of Sony TV set and it was definitely designed to support teletext. I've got another remote with the wrong order which came with a KWorld DVB card bought from Maplins, a major high street electronics chain. That remote isn't really usable with VDR anyway though, because the colours are also play, pause, stop and record. I suppose they didn't think that people would use teletext or MHEG while watching a recording, and there is no standard for the way that VDR uses the colours. I can't use the remote that came with my other card (Hauppauge) because the current kernel/DVB drivers aren't compatible with it (for at least the 2nd time in hstory). So I'm making do with a wireless keyboard until that's fixed. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Two problems with vdr 1.7.16-1devel2
I'm currently experiencing two problems with vdr 1.7.16-1devel2. The first problem is that if I fast forward or rewind, when I return to normal playback the stream resumes from wherever I started the ff/rew instead of where I stopped it. That's with vdr-sxfe on remote clients, I'm not sure whether it does the same if the client is on the same PC as vdr. The second problem is a memory leak. It's not too bad, but I have to restart VDR about twice a week to make sure there's no swapping and plenty of memory free for caching on a 2GB x86_64 system. As well as xineliboutput I'm also using the eepg and remote plugins. All from Tobias Grimm's debian repository. Are these known problems, perhaps fixed in a later release of upstream VDR? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-sxfe not working
vdr-sxfe isn't working for me at the moment. I'm using 1.0.6+cvs20110213.0131-1 from Tobias Grimm's repository. I've tried it on two different PCs, both running Debian unstable amd64; neither of them are the same PC VDR is running on. I can't check it on my VDR box at the moment, but it did work a couple of days ago and I don't think it's been upgraded since. It prints: vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.19, using xine-lib 1.1.19) VDR server not given, searching ... Found VDR server: host 192.168.1.68, port 37890 [5697] [vdr-fe]GNOME screensaver disabled [5697] [xine-vo ] wire_video_driver() FAILED (vo_driver != vos_driver) [5697] [vdr-fe]wire_video_driver() for osdscaler failed [5697] [xine-vo ] wire_video_driver() FAILED (vo_driver != vos_driver) [5697] [vdr-fe]wire_video_driver() for osdreorder failed Segmentation fault I can't get a useful backtrace, because it's stripped. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe not working
On Sun, 27 Feb 2011 20:55:47 +0100 Halim Sahin halim.sa...@t-online.de wrote: Which output driver have you tried? I've tried with no video.driver setting (with nouveau and nvidia X drivers), and also setting it to xv, opengl and sdl (with nvidia). They all crash in the same way. It seems that libxine fails with it. Can you please also post the full call? I just called vdr-sxfe with no arguments. But I've discovered the problem is because Debian's libxine1 packages now have a newer version than Tobias'. I've had to downgrade them all because the standard packages don't seem to be compatible with VDR 1.7. Tobias, any chance of updated packages so I can use apt-get (dist-)upgrade without having to fix xine ever time? Or is there a way to tie packages to a certain repository without necessarily having to pin the current version? There's also a memory leak in vdr 1.7.16-1devel2 or something it's linked with, so if that's known and fixed upstream an update for that would be useful too. On Sun, Feb 27, 2011 at 07:32:10PM +, Tony Houghton wrote: vdr-sxfe isn't working for me at the moment. I'm using 1.0.6+cvs20110213.0131-1 from Tobias Grimm's repository. I've tried it on two different PCs, both running Debian unstable amd64; neither of them are the same PC VDR is running on. I can't check it on my VDR box at the moment, but it did work a couple of days ago and I don't think it's been upgraded since. It prints: vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.19, using xine-lib 1.1.19) VDR server not given, searching ... Found VDR server: host 192.168.1.68, port 37890 [5697] [vdr-fe]GNOME screensaver disabled [5697] [xine-vo ] wire_video_driver() FAILED (vo_driver != vos_driver) [5697] [vdr-fe]wire_video_driver() for osdscaler failed [5697] [xine-vo ] wire_video_driver() FAILED (vo_driver != vos_driver) [5697] [vdr-fe]wire_video_driver() for osdreorder failed Segmentation fault I can't get a useful backtrace, because it's stripped. ___ 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] Deinterlace video (was: Replacing aging VDR for DVB-S2)
On Fri, 28 Jan 2011 09:57:50 + (GMT) Stuart Morris stuart_mor...@talk21.com wrote: Standard definition video is going to be harder than I thought. I used xrandr to set this mode via HDMI to my LCD TV: # 1440x576i @ 50Hz (EIA/CEA-861B) ModeLine 1440x576 27.000 1440 1464 1590 1728 576 581 587 625 -hsync -vsync Interlace The TV reported mode 576i ok, but the desktop graphics were unreadable. I tried to view an interlaced standard def video using my little test application and it looked awful. However the 1080i mode worked very well: # 1920x1080i @ 50Hz (EIA/CEA-861B) Modeline 1920x1080 74.250 1920 2448 2492 2640 1080 1085 1095 1125 +hsync +vsync Interlace I think for standard definition video via HDMI there will be a need to upscale to a resolution better supported by HDMI and that requires inverse telecine and deinterlacing. This may still be within the capabilities of todays low power systems. My little test has staisfied me that 1080i or 1080p video can be displayed with interlaced output. Stuart BTW my hardware setup was an old Sony KDL32V2000, and AMD HD4200 integrated graphics with the AMD closed driver. I have the same model of TV (I still think of mine as quite new!). For SD I just use 1280x720 progressive. The PC can deinterlace and upscale 576i with negligible CPU/GPU. I have to say xine's software rendering doesn't give as good a picture as the TV's DVB-T, but I thought subjectively upscaling to 720p looked better than using a native 576 line mode. I haven't had much success with libxine and VDPAU so far, but I haven't tried since updating my NVidia drivers etc to Debian experimental (260.19.21). The unstable ones are quite out of date (195.36.31) because of the impending Debian release. I've had VDPAU working OK in mplayer for ages though. The TV's 1280x720 modes are better for video than the 1360x768 native resolution because it automatically turns on some processing and colour balance features, but the overscan and scaling make it unsuitable for the desktop. Another feature of this TV is that 1280x720 forces 16:9, but 720x576 enables the various options for 4:3 (centre, zoom, smart, 14:9) so you could use mode switching as a form of aspect ratio signalling. However, changing mode causes the picture and sound to blank out for several seconds :-(. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)
On Wed, 19 Jan 2011 12:36:19 + (GMT) Stuart Morris stuart_mor...@talk21.com wrote: For progressive HD material I have to manually turn off deinterlacing, then turn it on again for interlaced material. That's annoying. I thought there was supposed to be a flag in MPEG meta data which indicates whether pairs of fields are interlaced or progressive so decoders can determine how to combine them without doing any complicated picture analysis. Are broadcasters not using the flag properly, or xine not reading it? xine-ui's preferences dialog has an option to disable interlacing for progressive material, have you set that in whichever front-end you're using? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Tue, 18 Jan 2011 15:06:50 +0200 Niko Mikkilä n...@phnet.fi wrote: On 2011-01-15 22:36 +, Tony Houghton wrote: BTW, speaking of temporal and spatial deinterlacing: AFAICT one means combining fields to provide maximum resolution with half the frame rate of the interlaced fields, and the other maximises the frame rate while discarding resolution; but which is which? And does NVidia's temporal spatial try to give the best of both worlds through some sort of interpolation? Temporal = motion adaptive deinterlacing at either half or full field rate. Some programs refer to the latter by 2x. Motion adaptive means that the filter detects interlaced parts of each frame and adjusts deinterlacing accordingly. This gives better quality at stationary parts. Temporal-spatial = Temporal with edge-directed interpolation to smooth jagged edges of moving objects. Both methods give about the same spatial and temporal resolution but temporal-spatial will look nicer. I still can't translate that explanation into simple mechanics. Is temporal like weave and spatial like bob or the other way round? Or something a little more sophisticated, interpolating parts of the picture belonging to the wrong field from previous and/or next frames? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sun, 16 Jan 2011 10:46:27 -0800 VDR User user@gmail.com wrote: On Sun, Jan 16, 2011 at 10:22 AM, Tony Houghton h...@realh.co.uk wrote: Maybe a better idea is to not assume anything at all, but rather actually look up real life data or just buy one and see for yourself (as I did). There's no reason to take guesses about any of this stuff, plenty of users have posts their results and specs at various forums. A good place to start would be nvnews.net and read the thread VDPAU testing tool. The results don't give the right information to determine how well a card can handle 1080i. You apparently don't know the results come from analyzing actual playback of actual samples of actual content. Yes, the data tells you exactly what kind of performance you can expect since it's generated from actual use cases. Again, stop assuming everything and turning your nose up at first-hand experience. I've ran those tests myself, obviously know what deinterlacers I'm using, and have watched plenty of content seeing the result with my own eyes from the hardware we're talking about. Additionally I've done the same with various hardware configurations.. What you're telling people simply doesn't agree with reality. I've attached the results of qvdpautest on my desktop PC. Some of the examples appeared to have no more than 2 or 3 frames. Does the test generate a 'realistic' stream using the same few source frames over and over again? Even if it does, it seems a rather narrow sample. The MIXER results show unrealistically high fps. Evidently the deinterlacing is not being performed at the same time as decoding in these tests. I suppose it's easy enough to caclulate the frame rate of both operations combined for a worst case, but how do you know to what extent they can be performed in parallel? qvdpautest 0.5.1 AMD Athlon(tm) II X4 620 Processor NVIDIA GPU GeForce 9800 GTX+ (G92) at PCI:1:0:0 (GPU-0) VDPAU API version : 1 VDPAU implementation : NVIDIA VDPAU Driver Shared Library 260.19.21 Thu Nov 4 21:46:12 PDT 2010 SURFACE GET BITS: 968.203 M/s SURFACE PUT BITS: 1021.38 M/s MPEG DECODING (1920x1080): 77 frames/s MPEG DECODING (1280x720): 154 frames/s H264 DECODING (1920x1080): 45 frames/s H264 DECODING (1280x720): 99 frames/s VC1 DECODING (1440x1080): 122 frames/s MIXER WEAVE (1920x1080): 2785 frames/s MIXER BOB (1920x1080): 4807 fields/s MIXER TEMPORAL (1920x1080): 1235 fields/s MIXER TEMPORAL + IVTC (1920x1080): 756 fields/s MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 1629 fields/s MIXER TEMPORAL_SPATIAL (1920x1080): 485 fields/s MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 387 fields/s MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 538 fields/s MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 1682 fields/s MULTITHREADED MPEG DECODING (1920x1080): 75 frames/s MULTITHREADED MIXER TEMPORAL (1920x1080): 1032 fields/s ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On 16/01/11 01:16, VDR User wrote: On Sat, Jan 15, 2011 at 2:36 PM, Tony Houghtonh...@realh.co.uk wrote: I wonder whether it might be possible to use a more eonomical card which is only powerful enough to decode 1080i without deinterlacing it and take advantage of the abundant CPU power most people have nowadays to perform software deinterlacing. It may not be possible to have something as sophisticated as NVidia's temporal + spatial, but some of the existing software filters should scale up to HD without overloading the CPU seeing as it wouldn't be doing the decoding too. Well, you can get a gt220 for around $40USD which does full rate temporal-spatial 1080i and allows you to use it with an old slow cpu's that are dirt cheap if you don't already have one collecting dust in your basement. Not sure how much more economical you can get aside of free. I also/mainly mean more economical in power consumption and ease of installation and cooling. Most cheap GT220s have fans (most likely cheap noisy ones) so I wouldn't want one of them in my HTPC. A fanless one might overheat being packed in closely with my DVB cards. But many motherboards already have integrated NVidia chipsets with HDMI, including audio, and basic VDPAU functionality. Mine is an 8200 and I know there's also been a lot of interest in Ion systems for HTPCs, so I think finding some way of getting these systems to display 1080i nicely should be a good move. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sun, 16 Jan 2011 09:33:30 -0800 VDR User user@gmail.com wrote: It's a bad assumption to say lesser expensive gt220 cards have cheap and noisy fans. It's simply not true. I've bought many graphics cards over the years and every time one came with a fan it's been noisy and I've replaced it with an aftermarket cooler with a bigger heatsink, and either a bigger fan(s) or no fan. People have different standards of noisy. If everyone was as demanding as me they wouldn't have considered using an XBox as a media player! The pictures of these cards are enough for me, I'm sticking to my assumption that if I bought a GT220 I'd have to budget for either getting a specialist model with silent cooler, or replacing the cooler myself. Maybe a better idea is to not assume anything at all, but rather actually look up real life data or just buy one and see for yourself (as I did). There's no reason to take guesses about any of this stuff, plenty of users have posts their results and specs at various forums. A good place to start would be nvnews.net and read the thread VDPAU testing tool. The results don't give the right information to determine how well a card can handle 1080i. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Mon, 17 Jan 2011 09:53:00 +1300 Simon Baxter linu...@nzbaxters.com wrote: I've avoided the noise problem by putting the VDR under the stairs where it can make as much noise as it likes. There it plugs in to a X-VGA splitter/broadcaster which sends duplicate signals over CAT-5 to each TV, where another small STB converts the signal back in to VGA. I've also put Infrared extenders everywhere. Result - a TV with no other hardware visible: no cables, no equipment, nothing. Just a TV on a wall bracket. Wife happy! Does that work with HD without much quality compromise? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On 15/01/11 21:49, VDR User wrote: On Sat, Jan 15, 2011 at 1:09 PM, Goga777goga...@bk.ru wrote: In general, get a gt220, as it has built in audio hardware, so that you should get audio without clock drift relative to the hdmi output. It is also powerfull enough to do temporal spatial deinterlacing on 1080i material. [Snip] what do you think about NVIDIA's GeForce GT 430 [Snip] It's a nice card but I'm not sure why you think it's the best choice for VDR/htpc. It's not going to give you any better image quality on HD content then you get from a gt220 at half the price. I don't see any advantage for most users in spending the extra money for one. Even if it does run cooler than a GT220 it can't be by much judging by the size of the heatsinks. Ones with fans might be too noisy in an HTPC, and ones without will need a well-ventilated case, bearing in mind they might be working quite hard decoding HD for long periods. So... I wonder whether it might be possible to use a more eonomical card which is only powerful enough to decode 1080i without deinterlacing it and take advantage of the abundant CPU power most people have nowadays to perform software deinterlacing. It may not be possible to have something as sophisticated as NVidia's temporal + spatial, but some of the existing software filters should scale up to HD without overloading the CPU seeing as it wouldn't be doing the decoding too. Alternatively, use software decoding, and hardware deinterlacing. Somewhere on linuxtv.org there's an article about using fairly simple OpenGL to mimic what happens to interlaced video on a CRT, but I don't know how good the results would look. BTW, speaking of temporal and spatial deinterlacing: AFAICT one means combining fields to provide maximum resolution with half the frame rate of the interlaced fields, and the other maximises the frame rate while discarding resolution; but which is which? And does NVidia's temporal + spatial try to give the best of both worlds through some sort of interpolation? -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Meridian
On 11/01/11 18:24, Tony Houghton wrote: Since my upgrade from VDR 1.6.0 to 1.7.16 I can't view my local ITV1 region (ITV1 Mer South) on Freesat. The EPG appears normal, but there's no picture or sound. ITV1 is OK on Freeview, as is the London version on Freesat. I think it was a bad connection on my satellite cable. I tried it in my old Sky box and that tuned to Meridian OK. When I connected it back to my PC VDR was then able to tune too. Strange how it only affected certain channels. Maybe mythtv will work now... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 13/01/11 00:11, VDR User wrote: So instead of maintaining just a plugin (which depends on ffmpeg decoding rather then xinelibs decoding), you think maintaining a new player altogether in addition to a plugin that streams data into it? Not to mention forcing VDR into being a backend only. I know some people have had success turning VDR into a server/client system but when I tried it, it was trash and a long way from usable in a 'stable' or 'daily use' VDR environment so I'm not that easily convinced the idea is a great one. The client-server model is almost essential to me. I wouldn't be interested in a solution that ties me to watching on one PC only and won't let me turn off playback without also preventing background recording. I'd be using mythtv by now if the DVB-S support in the setup tool wasn't completely broken. VDR's inherent limitations are that you can't have more than one client using it at once with separate OSDs etc, but that's acceptable to me as long as I have a choice of which room to watch in. Client-server doesn't have to make it unreliable, but admittedly it does increase complexity and therefore the likelihood of bugs. If written in a modular way the same bits of code could be used in two different plugins, one completely inetgrated and one client-server, so I won't say I'm completely disinterested in an all-in-one plugin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 13/01/11 16:50, Timothy D. Lenz wrote: And you are back to layer on layer on layer. If someone is going to write something, let it be the plugin that talks to vdr and ffmpeg. Forget xineliboutput, libxine, etc. The more middle ware we can dump the better. So maybe your needs would be best served by getting the softdevice plugin actively maintained again, including a developer with an interest in VDPAU. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 13/01/11 18:57, VDR User wrote: I agree, the less layer upon layer upon layer, the better. I also want to point out that there are a large number of users who have dedicated VDR boxes connected directly to tv's in an htpc environment, using only a remote control to navigate the menus and ssh for box maintenance. Not computer monitors, using VDR in a window in a desktop environment. The second you've required the user to have a full blown desktop, you've entered the realm of poor design. The ideal situation would be to have minimal requirements/dependencies and no bloat. Client-server doesn't require a desktop environment. You can just as easily arrange for the player client to start automatically and have VDR handle the remote control. My preference for being able to turn the player off goes back a long way though, to when VDR didn't have good support for playing other video files. There are a lot of people who also use XBMC etc. Additionally, an OSD that takes advantage of vdpau as well so you not only get full HDTV, but also a full high resolution/high color OSD with low hardware requirements cost to the user to go along with it. I know the OSD has been a point of debate but the truth is people do spend a lot of time in the OSD and because of that, there's no reason that can't be an enjoyable user experience. Chalking it up as mere eye candy completely disregards that fact. It's no different to the reason why people put nice stereos in their car... to have a better experience while using it. Given the choice between a nice Benz or a base model Kia...how many people would actually choose the Kia? Not many, so lets not pretend otherwise. AIUI VDR generates the OSD as a bitmap no matter which output plugin is used and the player only has the choice of how to overlay it on the video. So getting it rendered by VDPAU would be easy enough, but to upgrade it to HD would probably need some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 12/01/11 18:09, Timothy D. Lenz wrote: xineliboutput still uses xine. So it sounds like you are saying dump vdr and keep xine. xine is the problem, not vdr. You misunderstand. xineliboutput has a number of components: 1. A stream server plugin. 2. An integrated player plugin based on xine. 3. Standalone xine-based players for connecting to the server. I propose using 1, ignoring 2 (you can disable it with CLI options, I do this anyway because it's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer. From xineliboutput's README: : (xine-lib is not required for server in network-only usage) network usage can include localhost. On 1/11/2011 1:41 PM, Tony Houghton wrote: On 11/01/11 20:20, Timothy D. Lenz wrote: I would prefer a ffmpeg (mplayer) based interface and dump xine because xine/vdpau combo doesn't properly handle problems with the atsc stream. What about something based on gstreamer? Someone who understands that could probably knock together a basic player that works with xineliboutput in one day, but working out how to get the OSD would be a bit harder. If whatever plugins gstreamer chooses automatically to handle the TS etc turn out not to be suitable it can easily be forced to use ffmpeg (or any other compatible plugin) instead. It also has VDPAU and VA plugins. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 11/01/11 12:16, Eric Valette wrote: https://launchpad.net/~yavdr/+archive/stable-vdr cause its ubuntu and he uses debian ? ;) The yavdr packages works fine on debian (or at least as on ubuntu)... Except that: The following packages have unmet dependencies: libxine2 : Depends: libmagickcore2 (= 7:6.5.7.8) but it is not installable Depends: libmagickwand2 (= 7:6.5.7.8) but it is not installable Depends: libmodplug0c2 (= 1:0.7-4.1) but it is not installable Depends: libmpcdec3 but it is not installable AFAICT those packages are obsolete in Debian Squeeze or newer. If I try to install them from Lenny I'll probably have problems with other things that depend on ImageMagick. And yavdr doesn't include sxfe for some reason. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 11/01/11 14:37, Gerald Dachs wrote: And yavdr doesn't include sxfe for some reason. That is complete nonsense: https://launchpad.net/~yavdr/+archive/stable-vdr/+files/xineliboutput-sxfe_1.0.6%2Bcvs20110110.1350-0yavdr0_i386.deb You could have just pointed out that launchpad's index only lists source packages so I had to search for xineliboutput instead of sxfe. But you went the extra mile with an insult and a link to a package guaranteed to be of no use to me. Thank you very much. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 11/01/11 15:51, Eric Valette wrote: On 01/11/2011 03:18 PM, Tony Houghton wrote: On 11/01/11 12:16, Eric Valette wrote: https://launchpad.net/~yavdr/+archive/stable-vdr cause its ubuntu and he uses debian ? ;) The yavdr packages works fine on debian (or at least as on ubuntu)... Except that: I have them running on my box.Your problem are with xine not vdr... True, but I think I need updated xine packages to go with VDR. The stock Debian unstable ones don't seem to work at all with VDR 1.7 (probably because of the change to TS format). Tobias Grimm's ones do, but VDPAU really isn't usable in that version, so I'll have to try compiling 1.2. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 11/01/11 18:23, Timothy D. Lenz wrote: xine-lib-1.2-vdpau is just a link to xine-lib-1.2. Use ether one and you get the same. You want: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2 and if you are using vdr-xine plugin: hg clone http://hg.debian.org/hg/xine-lib/xine-ui/ I prefer to use the vdr-sxfe frontend. I presume it does work with xinelib 1.2 because it's present in yavdr, but it's a pity it's bundled with the VDR plugin, from the point of view of building just the frontend because I've already got the VDR plugin catered for. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdradmin timer summary (was vdradmin recording description)
On 11/01/11 20:17, VDR User wrote: On Tue, Jan 11, 2011 at 10:28 AM, Tony Houghtonh...@realh.co.uk wrote: When setting a timer with vdradmin the popup includes a box which is supposed to contain the programme description. This used to work, but hasn't worked for me, literally for years. I've just ignored it until now, but it would be something nice to have back now I can be bothered to mention it. Any ideas? There is no program description, only title of recording and summary. Which are you referring to? I would guess summary but you never know with people sometimes, so... Yes, I meant the Summary. And I should also have said timer in the subject, not recording. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 11/01/11 20:20, Timothy D. Lenz wrote: I would prefer a ffmpeg (mplayer) based interface and dump xine because xine/vdpau combo doesn't properly handle problems with the atsc stream. What about something based on gstreamer? Someone who understands that could probably knock together a basic player that works with xineliboutput in one day, but working out how to get the OSD would be a bit harder. If whatever plugins gstreamer chooses automatically to handle the TS etc turn out not to be suitable it can easily be forced to use ffmpeg (or any other compatible plugin) instead. It also has VDPAU and VA plugins. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Meridian
On 11/01/11 20:20, Luca Olivetti wrote: Al 11/01/11 19:24, En/na Tony Houghton ha escrit: Since my upgrade from VDR 1.6.0 to 1.7.16 I can't view my local ITV1 region (ITV1 Mer South) on Freesat. The EPG appears normal, but there's no picture or sound. ITV1 is OK on Freeview, as is the London version on Freesat. The log says: Jan 11 18:07:57 htpc vdr: [10023] switching to channel 103 Jan 11 18:07:57 htpc vdr: [10023] setstatus 0 Jan 11 18:08:06 htpc vdr: [10027] frontend 0/0 timed out while tuning to channel+ 103, tp 110891 The channels.conf entry (which I've checked is up-to-date) is: ITV1 Mer South;BSkyB:10891:hC56:S28.2E:22000:3336=2:3337=...@4:2344:0:10140:2:20+53:0 110891 is not the same as 10891. Strange. That's definitely what it says in the log. Does tp show the frequency it's trying to tune to, or is it adding an extra 1 in the log for some reason? I didn't think of trying to tune to other channels on that transponder, and I can't ATM because the family are watching a recording. I'll let you know later. BTW, this is my entry for it ITV1 Meridian S;BSkyB:10891:HC56M2O0S0:S28.2E:22000:3336=2:3337=...@4:2344:0:10140:2:2053:0 Essentially the same as mine I think. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Meridian
On 11/01/11 23:42, Luca Olivetti wrote: Al 11/01/11 21:50, En/na Tony Houghton ha escrit: BTW, this is my entry for it ITV1 Meridian S;BSkyB:10891:HC56M2O0S0:S28.2E:22000:3336=2:3337=...@4:2344:0:10140:2:2053:0 Essentially the same as mine I think. Well, yours is missing some of the parameters (i.e. it's missing the M2O0S0), and the TID seems wrong (20+53 instead of 2053), so I doubt that your entry has been auto updated by vdr. None of my other channels have the M, O and S parameters either but they work. If that is the cause I guess it's only the M that's important without DVB-S2. I'll rewrite my script to include that. The + got into my message by accident, I must have pasted it from vim which uses + as a wrap indicator. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EPG corruption
I noticed a problem in VDR's EPG today, using vdradmin. The problem programme is Malcolm in the Middle at 18:00-18:25 on Friday 14/01/11 on UK DVB-T (Freeview) channel Fiver. When I click on the link for the programme description I get the details for the following programme, Zoo Days, instead of Malcolm. I've tried deleting epg.data and restarting, but the same thing happened. But when I ran boxstard, which has EIT harvesting, that showed the correct details. Can any other UK VDR users confirm or deny this? I'm using 1.6.0-19.2 from Debian unstable amd64, which is the stock source package of 1.6.0-19.1 to which I've added the Freesat patch. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Developer versions
I don't find VDR 1.6.0 very reliable and I'm wondering whether 1.7 is mature enough now to be worth setting up. At the moment I use Debian packages and although I have to recompile it to add the Freesat patch it's still a lot easier than gathering the bits and pieces and getting it to live nicely on my system. Any chance of a 1.8 release soon? I'd also be interested in the developer version of xine with VDPAU support. The trouble is there's a bewildering set of mercurial branches. There are some libxine2 packages in Debian experimental, but there don't seem to be any packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they are. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 10/01/11 19:28, Tobias Grimm wrote: Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton: I'd also be interested in the developer version of xine with VDPAU support. The trouble is there's a bewildering set of mercurial branches. There are some libxine2 packages in Debian experimental, but there don't seem to be any packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze. deb http://e-tobi.net/vdr-experimental squeeze vdr-multipatch addons base backports deb-src http://e-tobi.net/vdr-experimental squeeze vdr-multipatch addons base backports I get a lot of audio problems too, I was hoping maybe this had improved, especially pulseaudio support, in the 1.2 branch. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 10/01/11 19:09, VDR User wrote: You appear to want xine-lib-1.2, although I have no clue why you would be confused about the trees. To my knowledge, there is only one available at: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2 That's fine if you know what you're looking for, but the front page of xine's official site links to the top-level of hg.debian.org which contains getting on for 50 xine-lib branches. Including xine-lib-1.2-vdpau which is apparently being developed alongside xine-lib-1.2 despite your saying it was merged in. It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it. My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary. I use my HTPC for other stuff as well as VDR so I'd rather hack VDR to make it compatible with a (some would say the) standard Linux distro than the other way round. Therefore I think the Debian packages' screwiness saves me a lot of hassle instead of adding to it. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 10/01/11 19:28, Tobias Grimm wrote: Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton: I'd also be interested in the developer version of xine with VDPAU support. The trouble is there's a bewildering set of mercurial branches. There are some libxine2 packages in Debian experimental, but there don't seem to be any packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze. deb http://e-tobi.net/vdr-experimental squeeze vdr-multipatch addons base backports deb-src http://e-tobi.net/vdr-experimental squeeze vdr-multipatch addons base backports I see you have VDR 1.7 packages there too, I'd definitely be interested in those. Would you recommend multipatch over standard? -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG corruption
On 10/01/11 22:03, Theunis Potgieter wrote: On 10 January 2011 20:44, Tony Houghtonh...@realh.co.uk wrote: I noticed a problem in VDR's EPG today, using vdradmin. The problem programme is Malcolm in the Middle at 18:00-18:25 on Friday 14/01/11 on UK DVB-T (Freeview) channel Fiver. When I click on the link for the programme description I get the details for the following programme, Zoo Days, instead of Malcolm. I've tried deleting epg.data and restarting, but the same thing happened. But when I ran boxstard, which has EIT harvesting, that showed the correct details. [Snip] I suspect vdr-admin hasn't synced in a while, do you see the same behavior with vdr-live? Not now, but I wouldn't have thought that was the reason because I tried vdradmin just after restarting VDR and the EPG was mostly empty; those events hadn't arrived yet. I think the broadcast EIT has been updated since then, because there are 2 episodes each day and when I looked in the afternoon the details were missing for the second episode every day, whereas now they're available. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 11/01/11 00:55, VDR User wrote: There's no hassle involved by avoiding using debian sources. If you ever decide you would like to try it and see, I'll even help you with a script that does it all automagically. Thanks, but I think I'll use Tobias' packages. It isn't just little things like editing a few paths in the Makefile I want to avoid, I also like runvdr supplied with Debian packages, I'd miss that. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On 10/01/11 22:36, Tobias Grimm wrote: Am Montag, den 10.01.2011, 20:56 + schrieb Tony Houghton: I see you have VDR 1.7 packages there too, I'd definitely be interested in those. Would you recommend multipatch over standard? Depends on your needs - decide for yourself - multipatch currently includes the following patches: http://tinyurl.com/6zljrra Hm, probably not unless ttxtsubs is useful in the UK. I've been using the Freesat patch up till now, but I'd probably be better off using the Eepg plugin. I can probably borrow Debian bits for that from yaVDR :). -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
