Re: [vdr] Launching vdr + xineliboutput at startup
On Monday 31 October 2011 08:07:10 Nicolas Huillard wrote:
Le vendredi 28 octobre 2011 à 22:59 +0200, Damien Bally a écrit :
I'm making some kind of embedded vdr distribution based on busybox and
minimal X11, the problem is I have no idea of how I can launch vdr and
xineliboutput at startup.
What I recently did, based on Debian + e-tobi + minimal X11 + vdr-sxfe:
* use nodm to auto-log-in and launch X11 (tweak /etc/default/nodm), and
relaunch in case of crash
* create a simple /var/lib/vdr/.xsession to run xcompmgr and vdr-sxfe
with proper options
* comment-out a few useless lines in /etc/X11/Xsession.options
* standard output and errors lies in /var/lib/vdr/.xsession-errors
The way I did it (hacked together from what I've done before and various
things I've found on t'internet!). I'm not saying it's the best way or perfect
but it works for me and I may improve it later on. This is on a basic Debian
installation.
Autologin: /etc/inittab:
Change 1:2345:respawn:/sbin/getty 38400 tty1 to
1:2345:respawn:/sbin/mingetty --autologin vdr tty1
(Autologin on tty1 as user vdr)
Start X when user vdr logs in on the console (and it isn't already running):
~vdr/.bashrc ends with:
if [ -z $DISPLAY ] [ $(tty) == /dev/tty1 ]; then
startx
fi
(This means I can su to the user vdr without it trying to run X all the time!)
Then set up the commands to run vdr-sxfe.
~vdr/.xinit contains:
#!/bin/sh
xsetroot -solid black
evilwm
xcompmgr -n
unclutter -idle 2
exec /home/vdr/bin/start_vdrfe
(Set the root window to black rather than the X checkerboard thing, although
htis doesn't seem to work! Run a very lightweight window manager. Run xcompmgr
to handle compositing for HUD. Run unclutter to hide the mouse cursor. Then
start my start+vdrfe script.)
~vdr/bin/start_vdrfe:
#!/bin/bash
FEOPTS=--fullscreen
FEOPTS=${FEOPTS} --reconnect
FEOPTS=${FEOPTS} --post method:tvtime=use_vo_driver
FEOPTS=${FEOPTS} --video=vdpau
FEOPTS=${FEOPTS} --audio=alsa:hw:1,7
FEOPTS=${FEOPTS} --hud
FEOPTS=${FEOPTS} --nokbd
FEOPTS=${FEOPTS} --silent
LOGFILE=/var/tmp/vdr-sxfe.log
mv $LOGFILE ${LOGFILE}.old
while (true)
do
vdr-sxfe $FEOPTS $LOGFILE
done
(vdr-sxfe options probably not optimal but it seems to work for now!)
As I say, there's many ways to do this and this is what I'm currently using
for the lightweight client I've just built.
I still have my remote receiver attached to the server and I have
commands.conf containing lines such as:
Restart vdr frontend: ssh vdrfe killall -KILL vdr-sxfe
for when the frontend hangs (seems to happen mainly when I skip forward
several times in quick succession). I also have a command set up to shut down
the client from the remote.
Cheers,
Laz
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput cvs won't compile
On Thursday 27 Oct 2011, Marco Göbenich wrote: Hi! I tried to compile xineliboutput from CVS, but I get an error message: xine_frontend_main.o: In function `main': xine_frontend_main.c:(.text+0x867): undefined reference to `EXIT' xine_frontend_main.c:(.text+0x895): undefined reference to `EXIT' xine_frontend_main.c:(.text+0x909): undefined reference to `EXIT' I looked at the source code but the EXIT macro is not defined. I had the same problem. It arose for me because HAVE_XCOMPOSITE was not being defined in features.h by the configure script. Adding the line #define HAVE_XCOMPOSITE 1 to features.h (along with the combination of other libraries configure had found) meant that all of the EXIT calls were removed by the preprocessor due to #ifdefs. Not the best of methods but it let me compile and it seems to work OK so far in my (very brief) tests. It may or may not work for you! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wanted VDR xineliboutput client
On Saturday 22 Oct 2011, M. Fiegert 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. I bought 2 years ago Zotac IONITX-A-E motherboard which came with atom CPU and nvidia gpu, at that time it cost about 200 euro. ... I made the small case myself and have I have 12 fan running in it in the slowest speed and the case/cpu/gpu temperatures remains under 50 c. I also have such a zotac board. Its running like a charm as a vdr client since almost two years COMPLETELEY NOISELESS (no fan, SSD)! You have Full HD over HDMI (and there is optical output, but I never tried to use). Definatly my recommendation if noise is a concern. see http://www.linuxtv.org/pipermail/vdr/2010-January/021920.html Did you ever upload some photos of how you fitted your Accelero S1? To follow up on this thread... (Most of this is found easily in README files, etc., but I find it useful to see the experience of others!) Following some of the comments on here, I have just obtained a Zotac IONITX-T along with a 32 GB SSD to build an HD capable vdr client. This board has an Intel Atom D525 CPU which is dual core but appears as 4 cores and Nvidia Ion graphics. It is also a fanless board but (for paranoia's sake while I'm testing things!) I've also fitted a 40-mm case fan. The case I've bought is an M350 from mini-itx.com (http://www.mini-itx.com/store/?c=54). This has a nicer appearance than the pictures make it seem! The ultimate plan is to hang it off the VESA mounting holes on the back of my tele'. On the new client, I have installed a very basic Debian system. I then build CVS (or git) ffmpeg, xine-lib, xine-ui (for testing things), and vdr-1.7.21, along with the CVS xineliboutput plugin. My main vdr box is running vdr-1.7.21 along with quite a few plugins. I replaced my current primary device (softdevice) with -P'xineliboutput -- local=none --remote=37890' and restarted vdr. I then ran vdr-sxfe on the client box and I had vdr output on the attached monitor (I'm jsut about to nip out to buy an HDMI cable! I assume there was sound too but didn't check this!) The performance with VDPAU is pretty impressive. top shows vdr using about 3% CPU for SD material and this increases to about 7% for HD channels. For comparison, my current vdr setup is a 2.66 GHz Pentium 4 with a Matrox G450 for output and this sually hovers around 30% CPU for SD material. I have yet to fiddle with most of the settings but if I use Hardware blending for the OSD it is amazingly crisp. However, the video does stutter slightly when the OSD changes (moving the cursor line down, for example) but that's probably liveable with! At present, I am running all plugins on the server and my remote is still attached to the server. I presume that I should really build / buy another remote receiver, hang it off the client, and use the --lirc argument to vdr-sxfe to forward lirc commands to the server. I also suspect that I can run full vdr on the client to allow me to use some plugins on there?! Not looked into that yet. I suspect I can probably just use vdr-sxfe as a basic frontend, with lirc forwarding so I can hide the server somewhere else... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FreeviewHD compressed EPG
On Monday 24 Oct 2011, Stuart Morris wrote: In the absence of a modification to the Eepg plugin to decompress the FreeviewHD EPG, I have applied the original Freesat.diff to my installation of VDR 1.7.21 and have achieved some success accessing the FreeviewHD EPG. The patch is here: http://www.rst38.org.uk/vdr/freesat.diff The first hunk fails to apply but this is ok because that part of the patch is relevant to freesat only. The decompressed EPG has many 'holes' in it due to incomplete Huffman lookup tables in the freesat.diff. I did manage to port the Freesat lookup tables from the Eepg plugin to the freesat.diff and I can now receive what appears to be the complete FreeviewHD EPG :-) Oooo...I'll try to give it a go in the next few days. I never saw any real difference from running the eepg plugin! What's the best way of filling in the gaps in the lookup tables? Modify the patch so that unknown sequences are dumped along with surrounding words so that they can be added by hand? How many gaps are you seeing at the moment? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wanted VDR xineliboutput client
On Saturday 22 October 2011 08:55:01 M. Fiegert 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. I bought 2 years ago Zotac IONITX-A-E motherboard which came with atom CPU and nvidia gpu, at that time it cost about 200 euro. ... I made the small case myself and have I have 12 fan running in it in the slowest speed and the case/cpu/gpu temperatures remains under 50 c. I also have such a zotac board. Its running like a charm as a vdr client since almost two years COMPLETELEY NOISELESS (no fan, SSD)! You have Full HD over HDMI (and there is optical output, but I never tried to use). Definatly my recommendation if noise is a concern. see http://www.linuxtv.org/pipermail/vdr/2010-January/021920.html Sounds good to me. My current vdr box needs upgrading at some point and it has started doing hard lockups in the psat few weeks (I suspect the PSU is on the way out. Rather than trying to track that down, maybe it's a hint that I need to upgrade to a new system! Is this running in a client-server setup? I.e. DVB devices in another box and then using the libxineoutput plugin? Does this setup give you full OSD access to timer programming, etc., from the client? (I think that is all meant to be straightforward but does it work in practice?!) Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Does VDR support overlapped recordings?
On Wednesday 05 Oct 2011, John Klimek wrote: Does VDR know if two programs are located on the same transponder so that it can allow both programs to record at the same time? (this would also help when extending recording times by a minute or two and thus create overlapped recordings even though they are on the same channel or transponder) Works a treat. vdr has so far recorded as many concurrent recordings as I've ever needed it to (about 6 or 7, maybe?!). Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eepg plugin + UK freeviewHD = }?Ln??X??Z?Z
On Saturday 17 September 2011 20:32:48 Stuart Morris wrote: I have installed the EEPG plugin from the experimental branch; http://projects.vdr-developer.org/projects/plg-eepg/repository/show?rev=exp erimental (last revision was 26/08/2011), but I am getting gibberish in the EPG for the FreeviewHD channels. Does anyone know of a fix for this? That's exactly what I was getting when I tried it a couple of weeks back: it didn't seem to touch the EPG for the HD channels (which are encoded) but I also saw it trying to decode the EPG for other channels so I was seeing gibberish creeping in at random for other channels. I gave up for now because I can only currently play back HD stuff off line on a beefier machine! As I understand it, it's all just meant to work. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eepg plugin with UK freeview (not freesat!) EPG
On Thursday 25 Aug 2011, Mario Schulz wrote: Am 21.08.2011 23:09, schrieb Laz: Does anyone know whether the eepg plugin should just work with the Huffman encoded EPG broadcast on Freeview (DVB-T) HD channels in the UK? (Someone mentioned it on here a week or so back.) Yes, it does (next DW already programmed). In a recent version Freesat huffman decoding has been destroyed, in the most recent version this should have already been fixes. Hmmm...When I tried it, it didn't seem to touch any of the EPG received from the HD channels, so it remained unreadable. I'll give it another go this weekend, and I'll enable a few more debug messages... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FreeviewHD success with Nanostick 290e
Hi Chris (and list) I've just been doing a bit more testing with my recently acquired Nanostick 290e... I added a fake channel with the frequency 61800 MHz (my HD mux), QAM256, and everything else set to auto or random values. I then switched to it. vdr then picked up BBC HD, ITV1 HD, Channel4 HD, and BBC One HD. It was clever enough to switch to the Nanostick for the HD mux because it's the only device that can do QAM256 (not sure if _only_ DVB-T2 includes QAM256 or whether my other devices are too old ot do it as part of DVB-T). I get now/next EPG for the HD channels but it's encrypted (it needs a plugin to decode, from what others have said). If I switch to BBC One HD, femon gives me a video bit-rate of about 7 Mbit / s and an audio bit-rate of about 150 kbit / s. It claims to have a signal strength of 70% but I'm not sure I believe that! By comparison, BBC One gives me something like 3 Mbit / sv video and 260 kbit / s audio, and signal strength of 70%. vdr has now written out the new entries to channels.conf: BBC HD;BBC:61800:B8C23D23M256Y0:T:0:101=27:102=eng@17,106=eng@17:0:0:17472:9018:16516:0 ITV1 HD;ITV:61800:B8C23D23M256Y0:T:0:201=27:202=eng@17,206=eng@17:0:0:17604:9018:16516:0 Channel 4 HD;CHANNEL FOUR:61800:B8C23D23M256Y0:T:0:301=27:302=eng@17,306=eng@17:0:0:17664:9018:16516:0 BBC One HD;BBC:61800:B8C23D23M256Y0:T:0:6601=27:6602=eng@17,6606=eng@17:0:0:17540:9018:16516:0 These are from the Emley Moor transmitter (I'm not sure how whether PIDs, etc., are the same between different transmitters but it might help someone.) I'm not seeing anything on my tele' but I suspect my output device (a Matrox G450 with softdevice) can't go up to that high a resolution! Actually, I don't think it will currently play anything other than MPEG2. I have a recording going from BBC One HD and there is a 1.ts file which is growing rapidly. I just played it back on a different PC. Mplayer output: Playing 1.ts. TS file format detected. VIDEO H264(pid=6601) AUDIO AAC LATM(pid=6602) SUB DVB(pid=6605) PROGRAM N. 132 FPS seems to be: 25.00 Load subtitles in ./ == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0-192000) Selected audio codec: [fflatm] afm: ffmpeg (FFmpeg AAC in LATM) == AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... Unsupported PixelFormat 61 Unsupported PixelFormat 53 [h264 @ 0xeccca0]mmco: unref short failure Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [vdpau] 1440x1080 = 1920x1080 Planar YV12 Looking good! As far as I can tell, it seems to be working. :-) Next step, get the epg sorted out... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FreeviewHD success with Nanostick 290e
On Friday 19 Aug 2011, Stuart Morris wrote: Hi I too have just acquired a 290e and I am having difficulty getting it to work with VDR. Apart from the flakey driver at the moment, 'seeding' VDR's channel.conf is difficult. I tried using w_scan like this: w_scan -c GB -o 7 -I my_init_tune_file My tuning file (UK Sandy Heath) contained 1 line like this: T 474166670 8MHz 2/3 NONE QAM256 32k 1/32 NONE w_scan produced this: BBC HD;BBC:474166670:I999B8C23D0M998T999G32Y0:T:27500:101:0:0:0:17472:0:0: 0 BBC One HD;BBC:474166670:I999B8C23D0M998T999G32Y0:T:27500:6601:0:0:0:17540:0:0 :0 ITV1 HD;ITV:474166670:I999B8C23D0M998T999G32Y0:T:27500:201:0:0:0:17603:0:0: 0 Channel 4 HD;CHANNEL FOUR:474166670:I999B8C23D0M998T999G32Y0:T:27500:301:0:0:0:17664:0:0:0 However, VDR uses the first available tuning device when one of these channels is selected, which happens to be a DVB-T device and not the 290e DVB-T2 device. Is this a problem with channels.conf or do I need to use a later version of VDR? I am currently using VDR 1.7.15. Laz how exactly did you 'seed' your channels.conf? I did have a go at modifying the output from w_scan and appending it to my channels.conf but it kept choking on it (probably my fault!). What I did was go to the channel list from within vdr and created a new channel with the correct frequency for the HD mux. I think the only other thing I changed was to set QAM256 and as many things as possible to auto. I then switched to that channel. Shortly afterwards, vdr had picked up the proper channels and added them to channels.conf. All I then had to do was delete the fake channel I created. This was with vdr-1.7.19 (currently running happily with 1.7.20): don't ask me whether anyhting drastic has changed since vdr-1.7.15 but you could check dvbdevice.c to see if QAM256 is defined in it. My 290e doesn't seem to want to tune to anything but the HD mux if I use scan, w_scan, etc. I will try again from withing vdr later on this evening. It's not really a problem for me if it refuses to tune to a DVB-T mux and only the DVB-T2 HD one: I've got another 4 DVB devices for the DVB-T channels! :-) I've just installed the eepg plugin and updated my config files for tv_grab_uk_rt to include the HD channels. It might be time to seriously consider a new output device... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK FreeviewHD and VDR
On Thursday 11 Aug 2011, Chris Rankin wrote: Hi, I currently use VDR to watch Freeview in the UK, and it works great with a Hauppauge NOVA-T-USB2 adapter. However, this adapter isn't compatible with DVB-T2 and so I've now ordered a nanoStick T2 290e and have upgraded to the Linux 3.0.1 kernel in eager anticipation. My ultimate goal is to use VDR to watch FreeviewHD, exactly as I've already been using it to watch Freeview, except that I understand that the EPG for the HD channels has been compressed using proprietary Huffman tables. I've already found this web site: http://www.rst38.org.uk/vdr/ The patch here for VDR (with separate drop in files freesat.t1 and freesat.t2) looks interesting, and would seem to allow VDR to read the compressed EPG in a transparent way. However, it has obviously not been merged to VDR in over 2 years, which would suggest that the VDR developers have rejected it for some reason. Could someone tell me what the recommended approach is for parsing a Huffman-compressed EPG with VDR please? I suspect that I can integrate this patch into VDR manually, but this isn't a viable long-term solution. I'm in exactly the same boat as you! I've been using vdr for about 8 years now but only for SD stuff. I'm about to order a new hard disk (for a different machine) and was very tempted to add a nanoStick T2 290e to the order! I'd be really interested to hear how youget on with the nanostick (the only info on it I can really find is at http://stevekerrison.com/290e/index.html: just had a quick look and he's updated it since I last looked! toried of reprogramming a broken nanostick and baking it in the oven!). Is the driver now mainstream and, essentially, fully working? It looks like it should do. Sod it: just added one to my order! ;-) I've been using xmltv for a while to grab epg data from the Radio Times xml streams. I'm sure they have dta for HD channels too. It also means you get 2 weeks' worth of data and lenghtier write-ups of films, etc. What output device are you using for HD? I'm currently using softdevice (which I'm still hacking to get stable with current vdr versions) with a Matrox card for output using DirectFB. I'm just starting to investigate whether it's possible to use VDPAU to do the meaty decoding and then sent the decoded frames to DirectFB (i.e. no need for X to be running). I _think_ this is possible to do: svn avidemux can use VDPAU to offload decoding, apparently. If that's not doable, I guess I'll build a new Ion-based box and use xine for output. The problem then is that you don't tend to get many PCI slots for DVB cards (well, not with the small Atom boards). Maybe I could just keep the current vdr box (2.66 MHz P4) and stick an Nvidia graphics card in it. Decisions decisions... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK FreeviewHD and VDR
On Friday 12 Aug 2011, Richard F wrote: Me too - noticed that DVB-T2 stick a while back. I have the same issue with changing the front-end, I'm particularly loathed to part with my mediaMVP's using VOMP with my headless server. This forms a good multi-user, functional, low power, low cost, reliable solution... who could want anything more ...until HD came along. Snap! I've also been using VOMP on the upstairs tele'! (Also handy when I've broken my output device downstairs!) There is an ongoing effort to re-purpose an HD streamer of some flavour for VOMP HD, but its not there yet. The drive now seems to be for a generic Android solution which sounds like a great idea. See http://forum.loggytronic.com/index.php?topic=526.15 I'll have to start reading that forum again..! I might try to implement it so that vdr can record HD stuff but I can only watch them off-line using mplayer or similar from another PC. At least to start with, anyway. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PES packets sent to cDevice::PlayVideo: only audio and video?
On Sunday 07 August 2011 10:33:30 Klaus Schmidinger wrote: On 01.08.2011 14:25, Laz wrote: I'm getting quite a few errors from avcodec complaining that decoded video frames have width and height set to 0. This tends to be at the start of a stream, i.e. on channel changing or starting playback. Are there any packets sent which don't contain any playable data that I need to test for and handle? If you're not sure, I suggest you only explicitly handle the packets you know you can handle, and ignore the rest. I've now changed a few libavcodec, libavformat, etc., functions for their new equivalents, which seems to have sorted out some of the random seg faults I was getting after a day or so of running. It all works but it's not perfect: it can't decode a number of frames at the start of the stream when vdr starts. I'm now dropping all frames before the first I-frame and it seems a bit happier but still complains about the first few frames (maybe I should look for the first GOP instead? I'm learning all about MPEG formats as I go here! ;-). I don't think it likes decoding frames when it doesn't know the width and height (and it won't let you force default values before decoding!!). I've yet to work out whereabouts in an MPEG stream the width and height are to be found (I'm scanning the source code of a number of applicaitons in parallel!) Unfortunately, the documentation for ffmpeg is a bit brief in places and nearly all example code I've seen is for video files with a well-defined beginning rather than a DVB stream that could be opened at any point! Maybe it's easier to just ignore the errors for the first few frames..! ;-) Maybe I should bite the bullet and implement a decoder for PlayTsVideo()..! That would certainly be a good idea. I've just been looking into that and it should be fairly easy: change the format from mpeg to mpegts and make sure I only get data with the desired PID. I'll need to switch between the two for backwards compatibility. One thing I have spotted is that if I play something at a slow trickspeed and then go back to play, the audio has carried on at normal speed and is a long way out of sync. I'm sometimes hearing (choppy) sound during slow trickspeed, although that's quite rare! I've not seen either of these before and I suspect it's something I've broken along the way. Or could this be down to way the data are passed to the output device now? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PES packets sent to cDevice::PlayVideo: only audio and video?
On Sunday 07 August 2011 17:10:04 Laz wrote: It all works but it's not perfect: it can't decode a number of frames at the start of the stream when vdr starts. I'm now dropping all frames before the first I-frame and it seems a bit happier but still complains about the first few frames (maybe I should look for the first GOP instead? I'm learning all about MPEG formats as I go here! ;-). I don't think it likes decoding frames when it doesn't know the width and height (and it won't let you force default values before decoding!!). I've yet to work out whereabouts in an MPEG stream the width and height are to be found (I'm scanning the source code of a number of applicaitons in parallel!) Unfortunately, the documentation for ffmpeg is a bit brief in places and nearly all example code I've seen is for video files with a well-defined beginning rather than a DVB stream that could be opened at any point! To reply to myself(!) dropping everything before the first sequence header (00 00 01 B3) seems to have sorted out the decoding errors. I was thinking I'd have to drop a lot of packets between the actual pictures but avcodec seems happy to be fed everything after the sequence header. Next step, implement PlayTsVideo and PlayTsAudio... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] will VDR run on this?
On Monday 01 Aug 2011, Arturo Martinez wrote: http://www.geek.com/articles/chips/raspberry-pi-25-pc-goes-into-alpha-p roduction-20110728/ Any thoughts? I've had vdr running on a Linksys NSLU2 before now! No output device, though, and no remote (but that could have been bodged with some soldering). More of a proof of prinicple than anything else, though. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] PES packets sent to cDevice::PlayVideo: only audio and video?
Hi, I'm tidying up changes made to the softdevice plugin to get it working with vdr 1.7.0 which uses TS for recordings. It all works fine pretty much most of but I have some errors I'd like to track down. Are the PES packets provided to the primary device's PlayVideo function purely video and audio packets? It looks to me like the PAT and PMT are stripped out so that only MPEG2 (no HD for me at the moment) audio and video packets should get to PlayVideo(), and so the primary device should play _all_ packets sent to it. Is this correct? I'm getting quite a few errors from avcodec complaining that decoded video frames have width and height set to 0. This tends to be at the start of a stream, i.e. on channel changing or starting playback. Are there any packets sent which don't contain any playable data that I need to test for and handle? Maybe I should bite the bullet and implement a decoder for PlayTsVideo()..! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer mode vs TS playback: any difference in TS streams for vdr.1.7.19?
On Monday 11 Jul 2011, Klaus Schmidinger wrote:
On 11.07.2011, at 03:21, Laz l...@club-burniston.co.uk wrote:
Hi,
I'm currently updating the softdevice plugin to work with the changes
to TS format that started with vdr-1.7.1 and also current versions
of ffmpeg (libavcodec does the actual decoding).
I've made some progress with vdr-1.7.19:
{snip}
In Transfer Mode onlx one single PAT/PMT is generated at the very start
of it, while a recording contains a PAT/PMT at the beginning of every
GOP.
I've made good progress with this now: it all seems to work after a bit of
a shaky start-up! It will only run if run from a script to restart it
multiple times.
There is something with the startup of softdevice that causes a
segmentation fault: it's level of error checking in it's startup neesd
improving. It can restart about five times or so before it starts
properly. I need to track down the source of this.
It can also take a few seconds for the video to appear when starting up,
changing channel, or starting or stopping a recording. Audio instantly
changes on all of these so the streams are there and can be decoded. (The
audio is used presented as is and the video is delayed or speeded up to
keep in sync.)
Once it has managed to start up and the video has appeared, it all seems
pretty stable. I can play old and new format recordings too.
Cheers,
Laz
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Transfer mode vs TS playback: any difference in TS streams for vdr.1.7.19?
Hi, I'm currently updating the softdevice plugin to work with the changes to TS format that started with vdr-1.7.1 and also current versions of ffmpeg (libavcodec does the actual decoding). I've made some progress with vdr-1.7.19: Old PES recordings play fine (as I'd hoped they would!) New TS recordings play: the video looks fine. PlayTSVideo convertes to PES and passes that to PlayVideo of the output device (I assume it would be relatively straightforward to implement a proper PlayTs using avcodec but that's for a later date!). The sound is totally messed up: just lots of random buzzing noises (not looked into the audio yet). Tranfer mode does not work at all, all I get is a black screen and silence. Before I dig into buffers, etc., is there any difference between the streams sent to PlayTS in transfer mode and in playback? I see that transfer mode generates a PAT/PMT on the fly and passes the stream directly to PlayTs. Does a similar thing happen to a recording, i.e. the PAT/PMT is added before writing to disk and then the stream sent during playback is identical to that which would have been sent if it had been watched in transfer mode? Does the output device ulitimately receive the same set of PES packets? Thanks, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer mode vs TS playback: any difference in TS streams for vdr.1.7.19?
On Monday 11 Jul 2011, Klaus Schmidinger wrote: On 11.07.2011, at 03:21, Laz l...@club-burniston.co.uk wrote: Hi, I'm currently updating the softdevice plugin to work with the changes to TS format that started with vdr-1.7.1 and also current versions of ffmpeg (libavcodec does the actual decoding). I've made some progress with vdr-1.7.19: Old PES recordings play fine (as I'd hoped they would!) New TS recordings play: the video looks fine. PlayTSVideo convertes to PES and passes that to PlayVideo of the output device (I assume it would be relatively straightforward to implement a proper PlayTs using avcodec but that's for a later date!). The sound is totally messed up: just lots of random buzzing noises (not looked into the audio yet). Tranfer mode does not work at all, all I get is a black screen and silence. Before I dig into buffers, etc., is there any difference between the streams sent to PlayTS in transfer mode and in playback? I see that transfer mode generates a PAT/PMT on the fly and passes the stream directly to PlayTs. Does a similar thing happen to a recording, i.e. the PAT/PMT is added before writing to disk and then the stream sent during playback is identical to that which would have been sent if it had been watched in transfer mode? Does the output device ulitimately receive the same set of PES packets? In Transfer Mode onlx one single PAT/PMT is generated at the very start of it, while a recording contains a PAT/PMT at the beginning of every GOP. Thanks for the quick response! :-) In that case, I suspect my problem lies somewhere in the buffering or timing. I will delve further... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Remote receiver options...
I've been following various threads over the past year or so exploring various options for having a server-client vdr setup and it got me thinking. I'm currently using a home-brew LIRC receiver attached to a serial port which works perfectly. The ION-based boards look very nice as a vdr front end (using xinelibout or some yet-to-be-written plugin!) because they can do hardware HD decoding. However, I suspect a lot of these lack a serial port so my simple LIRC receiver would be no good. What are others doing in this sort of situation? USB-based receiver (there are a couple described at lirc.org), or do most of the ION boards still have a serial header (must admit, not looked into this properly yet!)? Several DVB devices do contain receivers but that pretty much defeats the object of having a server containing DVB devices and a client just for viewing. It all looks nice in principle but any lack of a remote is a deal breaker! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On Monday 10 Jan 2011, 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 Intriguing... I've always built vdr and a range of plugins from source, all under Debian. I've just been browsing the contents of your repository and I see that you do have what looks like most of the plugins I'm currently using in there. One question before I test your pre-compiled version... I'm currently using the softdevice plugin but I've never managed to get it to work with any versions of vdr newer than 1.7.0 (probably due to the change to TS). You have the softdevice built against vdr-1.7.16 in your repository. Does this work properly or has it just that it compiles and hasn't been widely tested? I think all I ever got was a black screen whenever I tried to build CVS softdevice against anything newer than 1.7.0! I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On Friday 14 Jan 2011, Tobi wrote: Am 14.01.2011 11:19, schrieb Laz: change to TS). You have the softdevice built against vdr-1.7.16 in your repository. Does this work properly or has it just that it compiles and hasn't been widely tested? I guess nobody tested it yet, including me. It doesn't contain any special patches for 1.7.16, so it will probably not work. I may give it a quick go: I'll have to work out whether installing it will break my currently working system. I'm pretty sure everything is under /usr/local and so shouldn't be overwritten: it pays to be paranoid! :-) I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup? As Steffen already answered, it's as easy as running debianize-vdr-plugin. This works for most of the plugins and should at least give you something, that can be easily tweaked. Sounds good. Where can I get the script? Is it in one of your packages? I assume I'd also need to install the source for vdr to build against, or does that get pulled in as a build dependency? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On Wednesday 12 Jan 2011, Morfsta wrote: Why not exclusively use the yaVDR repositories? My winter project has been to migrate my old hand compiled VDR-1.7.0 system using Reel EHD to yaVDR (distro) using a Nvidia GT210 with HDMI audio. Its taken a bit of tweaking to get somewhere near (mostly addressing audio sync issues when I used the motherboard sound card via SPDIF) but now I can get HD video with multichannel audio through VDR and also switch from the VDR main menu into Boxee (need to add this yourself) to handle playing local media (and free movies provided in the library) as well as running apps such as BBC iplayer and all the hundreds of other TV apps available (You Tube, Browser, Flickr, CNET, NASA TV etc). Sounds good. How are you running iPlayer, etc.? Through Firefox or equivalent? My current setup headless setup (control by remote only) so I can't run anything else like a browser withough ssh-ing in (and I'd need X, too!). If I change it all and am forced to use X for the video output, I could also run other apps too, although it would be nice to do it all from just the remote... I also compiled up the vomp mediaplayer plugin to drive my 2 Hauppauge Media MVPs (TV and media distributed through the house) and hooked it up to my rotor (rotor plugin seems pretty unstable though and crashes VDR regularly) and use channel scan to find sat channels. I've got a couple of Media MVPs hanging off of my setup too! They won't do HD, though. :-( Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK users - multiple BBC One/Two/News in channels list
On Wednesday 03 Nov 2010, Torgeir Veimo wrote: On 4 November 2010 09:24, Alasdair Campbell alcoh...@gmail.com wrote: After leaving it for a few hours this is what I have, note BBC ONE at the very bottom, the EPG is available here but no video stream, same with BBC TWO elsewhere. Here's my last working one, from two and a half year ago. Notice the frequencies are different; BBC ONE;BBC:506000:C34D34M16B8T2G32Y0:T:27500:600:601=eng,602=eng:0:0:4164 :9018:4100:0 BBC TWO;BBC:506000:C34D34M16B8T2G32Y0:T:27500:610:611=eng,612=eng:0:0:4228 :9018:4100:0 ITV1;ITV:482000:B8:T:27500:520:521=eng,522=eng:0:0:8261:9018:8197:0 Channel 4;Channel 4 TV:482000:B8:T:27500:560+8190:561=eng,562=eng:0:0:8384:9018:8197:0 Five;five:562000:B8:T:27500:6017:6018=eng,6019=eng:0:0:12866:9018:12290 :0 ITV2;ITV:482000:B8:T:27500:530:531=eng,532=eng:0:0:8325:9018:8197:0 ITV3;ITV:482000:B8:T:27500:540:541=eng,542=eng:0:0:8294:9018:8197:0 E4;Channel 4 TV:482000:B8:T:27500:570+8190:571=eng,572=eng:0:0:8448:9018:8197:0 More 4;Channel 4 TV:482000:B8:T:27500:590+8190:591=eng,592=eng:0:0:8442:9018:8197:0 Five Life;five:562000:B8:T:27500:6673:6674=eng,6675=eng:0:0:12928:9018:1229 0:0 Five US;five:562000:B8:T:27500:6689:6690=eng,6691=eng:0:0:12992:9018:12290: 0 Film4;Channel 4 TV:538000:B8:T:27500:0:0:0:0:27136:9018:24576:0 BBC THREE;BSkyB:10773:h:S28.2E:22000:5200:5201=eng,5202=NAR:5203:0:6319:2: 2045:0 BBC FOUR;BSkyB:10773:h:S28.2E:22000:5300:5301=eng,5302=NAR:5303:0:6316:2:2 045:0 ITV4;ITV:482000:B8:T:27500:600:601=eng,602=eng:0:0:8353:9018:8197:0 UKTV History;UKTV:538000:B8:T:27500:301:302=eng,304=eng:0:0:25792:9018:2457 6:0 One thing that can be a pain is having to manually reorder the channel list when new channels are added or they change what their assigned channel number is. Or new channels appear right at the end of the channel list (which still includes out-dated channels!). It would be nice if vdr had an option to set channel numbers based on the values that are encoded into the streams. I don't know enough about DVB standards to know where to find those numbers (LCN, Logical Channel Numbers, I think) but I do seem to remember someone on here a couple of years back mentioning a script which would reorder the channel listing to the correct numbering. Actually, I think that scan has an option to add the LCNs to a generated channels.conf. A bit of digging finds: The channel numbers can be found in the NIT table as the user-defined descriptor 0x83 and each channel number has a corresponding Service ID which is included in the descriptor Now...would it be as simple as extracting the LCN and then calling cChannel-SetNumber() for the relevant channel? Does a new channels.conf then get written (at some point) including the relevant :@number entries so that it all works? I might have a go to see if I can get this working but it won't be for a while due to other commitments. I realise that a lot of people don't worry about channel numbers but it sort of makes sense to me, at least for DVB-T where there are significantly fewer channels than on DVB-S, for example. It's also the way that proper STBs do it and most people (at least in the UK) would expect their normal channel numbers. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Mini-itx ION motherboards
On Friday 27 Aug 2010, master.of.brainless.thi...@gmx.net wrote: Am Thu, 26 Aug 2010 23:23:30 +0200 schrieb vdr-requ...@linuxtv.org: (although a lack of PCI slots is a tad worrying, at least for the small form-factor boards!). perhaps the pov 330-1 ion board? http://www.pointofview-online.com/showroom.php?shop_mode=product_detail product_id=117 it has a pci slot, but is it small enough for you? though i have problems finding it online to buy cause all search enginge just show me the pov 330, without -1. this is the board i would like to buy me next... Looks good. However, I have to decide whether I am going to go for a separate server containing all of my DVB devices and run a mini-itx frontend with an SSD drive and no DVB devices, or try to hang everything off a single mini-itx board. (My experiences with USB DVB devices hasn't been particularly good in the past because the devices kept on randomly disconnecting themselves, although it might be possible to blame the Via chipset for some of that!) I see that there are a few ION2 boards appearing now: does ION2 have any real advantages over ION? I found a couple of reviews that said they were almost identical! I need to have a fiddle to see if I can get a frontend and backend working on different machines how I hope I can, i.e. it all behaving as if it's a single vdr box in terms of remote (LIRC), setting timers, etc. What is currently looking nice is a case such as: http://www.mini-itx.com/store/?c=3#m200-lcd or http://www.mini-itx.com/store/?c=3#m300-lcd which have an LCD display (text only, unfortunately) and 12 buttons, all which connects to a USB port as a standard input device. Being able to set timers without turning on the TV is a nice feature! :-) Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
On Thursday 26 Aug 2010, Thomas Hilber wrote: When I started to setup my VDPAU machines (end of last year) I first made sure that the Xserver really is running a 50Hz modeline. I mostly play 25/50Hz streams. This way I found an Xserver bug/misbehavior. Only if I explicitly set the modeline params manually in xorg.conf I get real 50Hz output (instead of 60Hz). Please see attached my xorg.conf. Always try: DISPLAY=:0 nvidia-settings --query RefreshRate to verify. Even the Xorg.0.log lies about the fact that 50Hz are active but in reality it uses 60Hz. Maybe nVidia has fixed that in the meantime. After this tuning to a channel with live ticker gives me perfect results. There is not any judder at all. The problem with all this juddering is that the symptom 'judder' alone gives you no hint at all about the root cause of the problem. I've been following this thread with interest... I had been happily running vdr-1.7.0 with a Matrox G450 video card, softdevice, and a CRT TV. At first, I was using a home-built VGA-SCART lead (these cards can generate composite sync so no need for combining sync signals), and then I found a VGA-sVideo cable (came with a similar graphics card at work, ahem!). Then my old TV blew up and I now have a full-HD LCD TV. I've been using the same setup with the new TV and it still works pretty well for the SD signals I can currently receive. HD is starting to appear in the UK and it seems like a good time to replace my current P4-based vdr box with a smaller, low power unit, and an Nvidia ION systems seems to be the current option (although a lack of PCI slots is a tad worrying, at least for the small form-factor boards!). A couple of quick questions... What is the best method for my current SD broadcasts: home-made VGA- SCART lead or HDMI? (Do any of these boards have sVideo these days?) Do I run the X server at the SD resolution or at 1920x1080 and let xine rescale rather than the TV? I'm guessing run the X server at 1920x1080 and then both SD and HD work easily together (with full HD OSD?). I toyed with the xine and the xineliboutput plugins a _long_ while back: which is the easiest option for getting VDPAU working? Thanks, Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.15 working with softdevice?
Hi, Does anyone have a working setup involving vdr-1.7.15 and softdevice? I ask because I've been happily using vdr-1.7.0 (the one just before changing the DVB driver version) with softdevice since vdr-1.7.0 was released. I finally took the plunge and built the new DVB drivers and grabbed the latest version of vdr and this also includes the changes from PES to TS. It _almost_ works: I get a second or so of live TV, then lots of stuttering, and then vdr restarts. It spews out lots of mpeg_decode_postinit() failure and Error while decoding video frame 0 errors, and also insufficient thread locking around avcodec_open/close() (I think recent versions of ffmpeg are much more picky about multiple threads in parallel: probably needs more mutex locks adding). I did find a patch on the softdevice-devel mailing list back in December (http://lists.berlios.de/pipermail/softdevice-devel/2009q4/003253.html) which sounded like it was a similar problem caused by a change to ffmpeg. That patch alters the timing between frames by using the variable repeat_pict provided by libavcodec. If I apply the patch, I get a seg fault because the parent structure hasn't been defined. I suspect further changes to ffmpeg since: it's a bit of a nightmare keeping up with changes there! My version of ffmpeg is current cvs but my vdr-1.7.0 build (with the same version of softdevice) runs fine built against it! I suspect I need to do a lot more digging here but before I do, I thought I'd check whether anyone has this working and if so, what version of ffmpef you're using. The softdevice project seems to have gone very quiet recently (why I'm posting here in the first instance!) which is a shame because it has just worked for me in the past with DirectFB output from a Matrox G450, with no extra layer of X required (this is a dedicated set-top-box affair). Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] mini-PCIE with Broadcom Crystal HD Hardware Decoder (BCM970012) for HD playback with free drivers
On Tuesday 05 Jan 2010, Tony Houghton wrote: I had problems with softdevice, including A/V sync, but I think that was one of the areas the developers were putting a lof of effort into improving. Another thing I like about the xine plugins is that you can leave VDR running in the background for recording and stop and start the player frontend at will. For me xineliboutput and vdr-fbfe worked very well on a Matrox G450 connected to a SD TV, except that it would drop quite a lot of frames to achieve A/V sync. I'm currently using a Matrox G450 with softdevice and it works pretty much flawlessly for me at the moment with a bog-standard CRT tele'. I agree with Timothy D. Lenz. VDR desperately needs a decent player that works on mainstream graphics cards and allows full use of the OSD along with miscellaneous other features tailored for TV viewing. vdr-sxfe is quite good, but not good enough. I'm watching this sort of thread with interest...no free HD content in the UK yet (at least over DVB-T) but it's on the way in the next few years. No immediate need for getting an HD tele' or beefing up my vdr box for HD playback but putting in a small, purpose-built decoder card definitely seems to be the way forward. It would be nice to see support for the Broadcom HD decoders in FFMPEG so they can be used by softdevice but I'm not holding my breath! Once I have HD transmissions at my disposal, I'll definitely be buying such a decoder card or whatever they've been superseded by! Maybe someone will also have made some DVB-T2 devices by then! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Windows remote client
On Thursday 20 Nov 2008, Alex Betis wrote: Hello all, Is there a plugin for VDR (I use 1.7.1) that allows a windows based client to watch the channels remotely? What windows based clients can I use in that case? Is there a network overhead for watching a stream? I mean if the stream is 5Mbit, will it take 5Mbit of my network or the traffic will take more? In case the client is used with a small window that can't show the whole picture, will the network load be reduced? One option is the vomp plugin which has a client built to run under windows. See: http://www.loggytronic.com/vomp.php I've only had a quick play with the windows client but it worked reasonably well. I _think_ it will do both live TV and recordings but, as I say, it was a while back that I tried the windows client (I regularly use the MediaMVP client, though, and it works really well). Other options might be streamdev and vlc? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Tuesday 07 Oct 2008, Malcolm Caldwell wrote: On Mon, 2008-10-06 at 11:11 +0200, Klaus Schmidinger wrote: I don't think it makes any sense to put actual channel numbers into each channel's line in channels.conf. For one, what if different providers want to use the same channel numbers? And: what if channels are moved around, inserted or deleted? It might not make sense in your environment. In the UK and here in Australia there are fixed, advertised channel numbers. It makes sense if something is advertised as being on channel 20, then pressing '2' and then '0' should tune to that channel. Makes sense means that I can describe it to my wife. Exactly. However, I do see Klaus's point too, and I always had visions of it never being in core vdr! If I had hundreds of satellite channels carefully organised, I'd be a tad hacked off if something helpfully renumbered them for me!! This is the sort of feature which would be ideal as a plugin, i.e. only those who are interested need to compile and use it. As to whether it is possible to obtain the relevant LCN info from the DVB stream is possible from a plugin or not (I'd have thought a patch would be needed for this but haven't looked yet), or whether it is possible to renumber channels from a plugin. I think I gave up before when I didn't see an easy cChannel.Renumber() function or similar but I could be misremembering. The channel numbers are implicitly derived from the position of each channel in the channels.conf file. Offsets can be suggested with :@nnn lines, but are only hints and may be ignored if there are too many channels before them to actually implement the desired numbers. Maybe I should try to explain this to my wife instead? ;-) As I say, I tend to check the numbering every now and then and reorder channels.conf by hand inserting lots of :@nnn place holders. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Sunday 05 Oct 2008, Gavin Hamill wrote: On Sun, 2008-10-05 at 15:10 +0100, Dave P wrote: A few months ago I posted a VDR patch to implement support for Freeview+, the cut-down version of TV-Anytime (ETSI TS 102 323) broadcast in the UK. I've prepared a new version against VDR 1.6.0-2, and included a simple Perl script which automatically creates timers for all of the programmes in a series. Run it overnight as a cron job and never miss your favourite series again! The patch is at http://www.pickles.me.uk/vdrtva-0.0.3.tar.gz Interesting stuff :) I don't suppose it's possible to implement this as a plugin rather than a patch to VDR's core? Is there not enough core exposed via the plugin API? I can't see the patch going into VDR core any time because it's focused squarely at UK users only and Klaus would never have a use for it (unlike the Premiere-specific multi-angle support) so I'm worried that a lot of users will be missing out, especially if they use a packaged VDR. Indeed it does look very interesting: it's really annoying when things get repeated several times during the week. Should make life a bit easier rather than making epgsearch look for really specific timers! I will try to give it a go. On another Freeview specific note, I'd love to have my channels renumbered to their proper Freeview numbers. At the moment, I have to go through and move them about by hand every time something changes! I don't think there is currently any support for assigning channels a specific number within vdr (probably not much point with gazillions of satellite channels but more useful with the handful of terrestrial Freeview ones in the UK). Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Monday 06 Oct 2008, Frank Scherthan wrote: Laz schrieb: On Sunday 05 Oct 2008, Gavin Hamill wrote: On Sun, 2008-10-05 at 15:10 +0100, Dave P wrote: On another Freeview specific note, I'd love to have my channels renumbered to their proper Freeview numbers. At the moment, I have to go through and move them about by hand every time something changes! I don't think there is currently any support for assigning channels a specific number within vdr (probably not much point with gazillions of satellite channels but more useful with the handful of terrestrial Freeview ones in the UK). man 5 vdr: A group delimiter can also be used to just set the next channel’s number, without an explicit delimiter text, as in :@201 That's what I mean by doing it by hand! My channels.conf is littered with those! ;) Would be nice if each channel entry had a field for channel number instead, especially when they helpfully decide to move a channel! It's also the way real set-top boxes do it. I think scan can output the channel numbers to a vdr-readable channels.conf but I think that just puts in a :@1, :@2, :@3, etc. every other line. Just doesn't seem neat to me, especially as the channel numbers are broadcast. I did start looking at this a while back but never got very far: might have another go... Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Saturday 06 September 2008 11:34:30 kafifi wrote: FULLACK Carsten and Davide. Klaus, Thanks a lot for your great job. Good news to hear that development will restart soon ;-) Ditto on all the above! I have been using vdr full time since about 2002. It suits my needs as a set-top-box rather than an all-singing all-dancing media-centre application (if need be, I can use plugins such as softplay or mplayer for playing back avis, etc. but that very rarely happens!). I have toyed with mythtv at times and it was a nightmare to set up and it only had very flakey DVB support at the time. I have always been impressed with the quality of the source code for vdr. It's the first proper C++ application I've had course to look through in any detail (many, many years of pure C behind me, though!) and I've pretty much learned all of the C++ I know from Klaus's well-laid out source code! :-) Many projects I've used over the years which I've built from CVS source are often broken spectacularly. By contrast, Klaus's development versions are usually pretty rock-solid. Any bugs can be quickly ironed out because Klaus knows _all_ that has been changed without having to backtrack through revision logs including changes from various coding styles! If a new feature is needed, a lot can be achieved with plugins, or create a patch and forward on to Klaus and the list. I'm sure Klaus takes on board all suggestions and - seeing as it is a hobby - will get to stuff eventually. I will not be leaving vdr any time soon! :-) Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RGB/PAL over VGA at variable frame rate
On Tuesday 22 Jul 2008, Thomas Hilber wrote:
solution
graphics cards basically are not designed for variable frame rates.
Once you have setup their timing you are not provided any means like
registers to synchronize the frame rate with external timers. But
that's exactly what's needed for signal output to stay in sync with the
frame rate provided by xine-lib or other software decoders.
To extend/reduce the overall time between vertical retrace I first
dynamically added/removed a few scanlines to the modeline but with bad
results. By doing so the picture was visibly jumping on the TV set.
{snippage}
Interesting...
I looked at this sort of thing a few years back and came to the conclusion
that the only cards that could be convinced to sync at such low rates,
i.e. 50 Hz for PAL, were the Matrox G400, G450, etc. Whenever I tried
setting modelines with any other cards, I never got any output or an
error when starting X.
I take it that more modern cards are a lot more flexible in this respect!
I'm currently using a G450 with softdevice connected to a CRT TV and it
works pretty well most of the time with the odd flicker due to dodgy sync
every now and than.
Using hardware to do the deinterlacing is _definitely_ the way forward,
especially for CRT. (Not sure whether LCDs display an interlaced
streame properly or whether they try to interpolate somehow and refresh
the whole screen at once. I'm not buying one until 1. terrestrial is
available in the UK, 2. my current TV dies, 3. there is a solution like
this which utilises older hardware!).
Looks interesting...
Cheers,
Laz
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] eHD, VDR and multimedia files
On Wednesday 23 Jul 2008, Niels Wagenaar wrote: Greetings to All, Yesterday I've received my Reel eHD so that I can enjoy hardware accelerated DVB-S/DVB-S2 playback/output on my VDR-1.7.0 installation in combination with the S2-3200. Everything works, image is very good and I can enjoy HDTV without framedrops or stuttering :) The tutorials on vdr-wiki.de were very helpfull to get it all working. So cheers for the person who wrote it! Looks good. Can anyone translate the tutorials and upload to http://www.linuxtv.org/vdrwiki/ for the non-German speakers among us? :-) Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD-TV hardware decoding on motherboard instead of waiting for FF DVB-S2 card
On Wednesday 06 Feb 2008, Ondrej Wisniewski wrote: With VDR getting ready for HD-TV it seems that today the MPEG4 decoding can only be done on a high end processor or an external decoder card. Many people are still waiting for a FF DVB-S2 card but it doesn't look very promising at the moment. So I was wondering if it would be possible to use the on board video decoder chips of the VIA EPIA boards like the VIA EPIA EX15000G http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboa rd_id=450 This board mounts a CX700M2 chipset which features MPEG2/4 hardware decoding. It has DVI and Y/Pb/Pr video output as well as analog and SPDIF audio (coaxial and optical). So that's everything we need, isn't it. I know, currently the OpenChrome video driver doesn't support MPEG2/4 video decoding for the CX700M2 and there are probably other things missing from the software support side. But from what I see, this or a similar motherboard in combination with a budget DVB-S2 card have all the hardware features that are needed to have HD-TV. So we actually have the proper hardware platform *today* for a quite a low budget. So if all the efforts go into driver and application development for such a platform, there is no need to wait for FF DVB-S2 cards. Or am I missing something here? I think the main problem here is Via not wanting to release information on their chipset to allow MPEG4 support to be built into OpenChrome or similar. MEPG2 decoding works (at least on the older Via chipsets...) but I think this was mostly reverse-engineered! I don't think MPEG4 decoding will be supported in this way for a very long time, unless Via have changed their attitudes. (Not really bothered looking into this because HD is years off in the UK where I am, unless you fork out lots to Sky!) It is a shame to have such hardware and not be able to use it!! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Output methods and WSS
On Tuesday 16 Oct 2007, Stuart Morris wrote: According to the MVPvdr website http://www.rst38.org.uk/mediamvp/mvpvdr.html there appears to be no way to set timers so I have never been tempted to try it out. I failed to get an early version of the MediaMVP plugin to work many years ago. Vomp is still being developed so maybe you should join the forum http://www.loggytronic.com/forum/ Vomp seems to work quite well. I have an older (H2) MediaMVP which I use on a tele' upstairs, mainly for watching recordings but live TV also works. I think it does have the ability to set timers (on the remote vdr server) but I've never tried that. I also have a newer (H4) MediaMVP which I've never managed to get to work but I think it's meant to. These things load a firmware using TFTP when you boot them and they seem quite picky about which files they will download (or not in the case of the newer one!). It was fairly easy to set the older one up but you do need a DHCP server (to point the MediaMVP at a TFTP server) and a TFTP server to serve the firmware. Both of these are built in to the vompserver plugin but I never managed to get them to work! I'm already running a DHCP server on a different machine so I'm using that to point the MediaMVP at my main vdr box which is running a stand-alone TFTP server. Might sound complicated but it works (at least for the older one!). Some things it is missing (as far as I can tell) are trickspeed playback and editing functions, and some of the remote buttons do different things from how I've got my main vdr remote set up. It allows playback of recordings to be resumed but it uses its own resume files, so if you are halfway through watching a recording on the real vdr system, it will replay from the beginning on the vomp box! I'm not sure I'd want it as my main way of using vdr (lacks some useful features) but is very good for use as a second system. Also much quieter than the old PC I had as a second vdr system upstairs! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Output methods and WSS
On Tuesday 16 Oct 2007, Laz wrote: Vomp seems to work quite well. I have an older (H2) MediaMVP which I use on a tele' upstairs, mainly for watching recordings but live TV also works. I think it does have the ability to set timers (on the remote vdr server) but I've never tried that. Forgot to add: there is also a windows version of the client software which runs on the MediaMVP. This means you can watch live TV, recordings, etc. in a window under m$ windross. Not sure if this has many advantages over something like a streaming plugin and a stream player. I suppose you can add timers. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dual Tuner Cards
On Monday 25 June 2007 09:53, Alex Stansfield wrote: Hi, This seems like a pretty dumb question but I hadn't seen it mentioned before and just wanted to check. I'm looking to buy a dual tuner card, most likely the WinTV Nova-T 500. My question is, as long as the card is supported in Linux will vdr treat it as two dvb-t devices? I've got one and it works a treat. It does just appear as two separate DVB devices. I did read stuff a while back about people getting USB disconnects from them at random but I've never seen that with mine. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR user input slowness
On Thursday 15 February 2007 11:30, Teemu Suikki wrote: On Thu, 15 Feb 2007, Teemu Suikki wrote: Why is the user input so slow? When I press a key in remote, there seems to be a random delay of 0-0.5sec or so.. Sometimes it's fast, sometimes not. It's fine in channel switching but really annoying when you a trying to input filenames or something. .. Replying to myself.. The problem seems to be in kernel level after all, I enabled ir_debug in budget-ci module and the same delay is there as well, debug log appears at the same time as vdr reacts to the keypress. This is a known driver problem: a link to a patch was posted a few weeks back which removes this delay. See: http://www.linuxtv.org/pipermail/vdr/2007-February/011994.html I've always had more success with a home-brew LIRC receiver on a serial port. Cheers, Laurence ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK Freeview Logical Channel Numbers
On Wednesday 14 February 2007 15:24, Andrew Herron wrote: Does anyone know if the Logical Channel Numbers that are used in the UK on Freeview DVB-T transmissions are currently handled by VDR in anyway? I'm pretty sure that they're currently ignored. I tend to hand edit my channels.conf every now and then to make sure channels are in the corerct order with their correct numbers. The scan utility can output a vdr-format channels.conf with the channel numbers included, too. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature Request: 10 Second Jump from BigPatch, switch timer
On Saturday 03 February 2007 18:03, VDR User wrote: On 2/2/07, martin [EMAIL PROTECTED] wrote: To be honest, i use BigPatch for just one reason. During playback, I can jump 10 sec + / - with the 1 and 3 keys. I can't live without this feature, because jumping 1 Minute is nice, but most of the times way too long. So, actually, adding this 10 seconds jump to the main part, would also help me a lot! Maybe Klaus will let the skip-time be user-definable in a future version, or maybe someone has already made a patch for it but for now why not just make your own small patch for it rather than apply BigPatch? I believe these are the lines in menu.c to modify: case kGreen: SkipSeconds(-60); break; case kYellow: SkipSeconds( 60); break; I always copy the relevant lines for kGreen and kYellow (near the end of menu.c), rename them to k1 and k3, and change the delay to 10 s, leaving Green and Yellow to stay as 1 min skip. The majority of advert breaks in the UK (on terrestrial channels) seem to be about 4 minutes (I've got another key set to skip 4 minutes forwards...) but some are +/- 10 or 20 s and being able to skip 10 s is very handy for me. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote: Marko Myllymaa [EMAIL PROTECTED] wrote: Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered. i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz. What type of remote receiver are you using? I've had delays with some remotes but not others: 1. USB2 Nova-T receiver with the remote plugin: works most of the time but goes through phases where it seems to be ignoring keypresses so I press the button again (several times!) and then a few seconds later it catches up and I end up in a different menu, etc. to what I wanted! Works OK but can be very annoying! Also gives the wrong codes, i.e. keys, sometimes which can be confusing! 2. PCI Nova-T receiver through lirc: works much better than the USB receiver but does feel as if there is a lag between pressing keys and things happening. Does sometimes do the buffering thing mentioned above but nowhere near as bad. 3. Home-made simple lirc receiver on a serial port through lirc: much more responsive than the two proper remote receivers! I would recommend this to anyone who can build the simple receiver. Finally got round to building another one for my main vdr system and it is so so much better now (was using the USB receiver previously). I never worked out where the delays occurred, i.e. whether it was down to the DVB drivers or vdr itself. Seeing as the lirc receiver works fine, I'd be suspicious of the driver. The above observations are on a 1.2 GHz Via Epia system, so not that powerful all things considered. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SetPlayMode() on radio channels
On Wednesday 31 January 2007 14:13, Thiemo wrote: Am Freitag, 26. Januar 2007 15:32 schrieb Klaus Schmidinger: Thiemo wrote: Hi, is there a special reason that SetPlayMode() is always called with pmAudioVideo even on radio channels instead of pmAudioOnly or pmAudioOnlyBlack? It would make things much easier if it would do so (for displaying a background image). Can you give me a hint where I could change this? pmAudioVideo is the default play mode for VDR, and by itself VDR doesn't use anything else. This was introduced in case a plugin wants to implement a player that needs a different play mode. When replaying a recording, VDR sets up a cDvbPlayerControl in maybe you got me wrong - i don't want this for replaying a recording but for live-broadcasts. (although replaying is an issue i did not think about yet). currently its realy a pain finding out if a stream is audio-only or not in the mpeg-player (where it does not belong imho). What would be nice is something like bool cRecording::IsRadio(). I was going to have a go at incorporating the code posted on this thread the other day by Reinhard Nissl but haven't got round to it yet. This could then also be used when determining recording lengths, skipping, etc. rather than treating all timings as video. Having said that, I tried to record a couple of sample bits of a radio channel the other day and they were pretty broken. :( Do radio recordings still work for other people or have I managed to break something?! I used to make quite a few but haven't done so in a while. This is vdr-1.5.0 and softdevice cvs. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Centralized VDR solution?
On Saturday 06 January 2007 20:16, Peer Oliver Schmidt wrote: Torgeir Veimo wrote: On Sat, 2007-01-06 at 20:10 +0100, Peer Oliver Schmidt wrote: Is there a solution (reliable) for this kind of system available? I am using Hauppauge MediaMVPs to connect to a central VDR system containing 3 DVB-S cards. VOMP is running on the MediaMVPs No dropped frames, bad av sync or other playback issues? Nothing that can't be fixed by either switching a channel or pause/play on the remote. This looks quite interesting... I've currently got about three full PCs using nfs-mounted /video directories. Would be a much nicer solution to use a thin client setup. What video output(s) has the MVP actually got? I've just been reading stuff on the web and I've seen composite, S-video, and RGB component mentioned in various places. Are there different versions of these things, apart from wired / wireless? Does it really work this well? I'm not too bothered about editing recordings from it (use vdrsync for that!) but setting timers would be useful. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New VDR hardware
On Thursday 04 January 2007 09:30, Torgeir Veimo wrote:
On 4 Jan 2007, at 09:20, Laz wrote:
Hmmm...I've got one of these and I've never seen it disconnect yet
(a few months so far...fingers crossed!).
It looks like this (am not sure why it actually causes my machine to
crash, it might be something related to irq sharing):
Jan 2 19:33:45 fink kernel: MT2060: PLL freq=562000kHz
f_lo1=1782000kHz f_lo2=1183850kHz
Jan 2 19:33:45 fink kernel: MT2060: PLL div1=111 num1=24 div2=73
num2=8115
Jan 2 19:33:45 fink kernel: MT2060: PLL [1..5]: 56 6f 3 fb 93
Jan 2 19:33:48 fink kernel: usb 8-1: USB disconnect, address 2
Jan 2 19:33:48 fink kernel: ehci_hcd :03:01.2: qh f7c40100 (#82)
state 4(has tds)
Jan 2 19:33:48 fink kernel: mt2060 I2C write failed
Jan 2 19:33:48 fink kernel: mt2060 I2C write failed
Jan 2 19:33:48 fink kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T
successfully deinitialized and disconnected.
Jan 2 19:33:48 fink kernel: BUG: unable to handle kernel paging
request at virtual address 2e313212
Jan 2 19:33:48 fink kernel: printing eip:
Jan 2 19:33:48 fink kernel: f8a23177
Jan 2 19:33:48 fink kernel: *pde =
Jan 2 19:33:48 fink kernel: Oops: [#1]
{snip}
I don't think I ever saw a kernel oops when my USB2 devices disconnected
themselves, just a non-descriptive USB disconnect message. I think
unplugging the cable from a working device does, though, so maybe my
external USB devices weren't disconnecting fully, somehow. This only ever
really happens when I hang two of the external USB2 Nova-T devices from
the same system.
Cheers,
Laz
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR deletes directories
On Monday 09 October 2006 15:50, Matthias Fechner wrote: Hi, I have the problem that VDR deletes directories in my /video0 or /video1 ... which not belongs to VDR. I use vdrconvert to convert my VDR recordings to DVDs so I have a directory /video1/filme which VDR deletes and vdrconvert breaks. Is it possible to deny the delete of this directory? I think the general consensus is, don't have non-vdr stuff under /video directories! Have you tried setting the permissions on the directories so they cannot be removed? (vdr is running as root here) Eeeek! Also makes permissions a bit more complex than just changing ownership to the non-vdr user. Can you put the directory elsewhere and use a symbolic link in /video, and check it exists before running vdrconvert? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
