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] 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] 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] 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 Saturday 27 August 2011 01:18:31 Tony Houghton wrote: > On Fri, 26 Aug 2011 20:42:38 +0100 > > Laz wrote: > > I thought it had been doing this scrambling when I tried it earlier > > in the week but have now proved it to myself. > > > > Time to start adding some more printfs... > > The first byte of encoded strings should be 0x1f, followed by 1 or 2 > indicating which table should be used (one is optimised for titles, the > other for descriptions). "Normal" strings either start with a printable > character for the default character set or a code < 0x20 indicating the > character set. I use eepg too, but I haven't noticed it scrambling > anything (this is probably the first time I've looked at QVC's schedule > though ;)). Over the evening, it scrambled more and more channels! :-s Thanks for the pointer to 0x1f! Now I know where to look. (I assume that eepg only decodes EPG that comes in "over the air" and doesn't touch any EPG alread stored.) 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 Friday 26 August 2011 13:33:52 Laz wrote: > 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... HD, ITV HD, and other encoded channels alone. It does, however, scramble the EPG for some other, totally unrelated channels on a range of MUXes! I presume it thinks it's encoded and tries to unencode it, scrambling it in the process. One channel EPG that becomes scrambled is QVC so no real loss there! ;-) I thought it had been doing this scrambling when I tried it earlier in the week but have now proved it to myself. Time to start adding some more printfs... 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] eepg plugin with UK freeview (not freesat!) EPG
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.) I'm pretty sure the EPG data is encoded in exactly the same way as it is on Freesat, i.e. DVB-S, and eepg can decode that EPG. I'm trying to work out whether it should currently be able to do it (and I need to configure something before it'll work), or whether I should try to add support for it. A quick scan of the source code looks like the terms "freesat" and "freeview" are used interchangably in it. Currently, I have completely garbled EPG on HD channels! I can add decoded EPG grabbed via xmltv but the EPG gets overwritten with the garbled version. (What's vdr's policy on EPG data added through SVDRP, etc., being overwritten by data from the EIT?) 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 Sunday 21 August 2011 02:35:53 you wrote: > I've finally managed to tune my 290e in as well. I have discovered that I > need to remove all of the 2-way splitters that I'd been using to connect > everything up to the wall socket, and then w_scan and scandvb can find the > HD signal. But my version of ffmpeg (0.6.3) is struggling to decode the > stream and so I'm not getting any sound. The pictures are OK, though. So > maybe it's just that this PC is slightly underpowered? (2x2.66GHz P4 Xeons > with HT enabled). I'll try using a beefier machine tomorrow. For me, it was actually very easy to get going: - install drivers (I'm currently on the ones pulled in by the media_build script but I htink the vanilla 3.0.x kernel drivers would have worked) - create a fake channel on the frequency of the HD mux and with QAM256 (I think vdr could find the new mux because I'd been getting loads of "can't tune to channel 0" messages for a while which I put down to the HD mux and not having anything that could tune to it at the time: maybe it would have "just worked" given time) - tune to the fake channel and let vdr add the real channels - delete the fake channel! My current vdr box isn't beefy enough to play back HD recordings (2.7 MHz P4) but it can happily record them and I can play back on my "main" PC using a vdpau-enabled Nvidia card. > And if I'm still getting a HD signal tomorrow, I'll know that my 2-way > splitters really are the problem too :-). Although the loss of the > splitters will be a problem in the long-term, because now I'm limited to > only one DVB-T/T2 receiver. My 290e doesn't want to tune to any of the SD muxes at all but works fine on the HD one! Could be faulty but if it works OK for HD it's fine for me! The signal from my aerial goes through an amplifier to another amplifier with four outputs! I could probably do with a new aerial!! The problem I currently have is the encoded epg from the HD channels. I've got eepg running now but I htink that only processes EPG from the DVB stream rather than processing existing EPG data. This is a problem because I'm downloading EPG from Radio Times and feeding it in using xmltv2vdr. Even so, I don't think eepg was unencoding any new EPG data. The epgsearch plugin manages to find A LOT of recordings when your EPG is garbled!! :-s One step at a time... 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
[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] 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] 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] 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] 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
[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] 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
Re: [vdr] VPS fallback patch
On Monday 18 Jul 2011, Dave wrote: > On Monday 18 July 2011 13:09:19 Laz wrote: > > I will have to give your patch a go becuase I've recently missed a > > few recordings due to tennis and football over-running!! > > > > I presume I need to set timers with no margin at the start and with > > vps enabled for all for this to work? > > In your setup.conf you should have: > > UseVps = 1 > VpsFallback = 1 > VpsMargin = 120 > > The last one sets the number of seconds before the scheduled start time > that VDR begins monitoring the p/f table for the event start. > > Also whenever you set a new timer you need to set the 'flag' field to 5 > - if using vdradmin-am tick the 'use VPS' box in the New Timer window > - as well as setting the start time with no margin. > > > Do I also need your tvanytime patch for this to work? I did try it a > > few days back with vdr-1.7.19 but I kept on gettign seg faults from > > calls to strcpyrealloc! I was, however, in the process of sorting > > out some other issues at the time so will have to try it again now > > that I've fixed the other problems! > > The TVAnytime patch includes this VPS Fallback patch, but you don't > need the rest of it just to do accurate recording. All looks good. Your small patch works but your TVAnytime patch causes me lots of segmentation faults! This is with vdr-1.7.19 having already been patched with the liemikuutio patch (I don't think it touches anything likely to affect this). An example: *** glibc detected *** /home/laz/dvb/vdr-1.7.19/vdr: malloc(): memory corruption: 0xb64a81b8 *** gdb backtrace: (gdb) bt #0 0xe424 in __kernel_vsyscall () #1 0xb7c5f911 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7c62d42 in abort () at abort.c:92 #3 0xb7c959d5 in __libc_message (do_abort=2, fmt=0xb7d6aa70 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xb7c9fac1 in malloc_printerr (action=, str=0x6 , ptr=0xb696b780) at malloc.c:6283 #5 0xb7ca28a4 in _int_malloc (av=, bytes=) at malloc.c:4396 #6 0xb7ca44ac in __libc_malloc (bytes=14) at malloc.c:3660 #7 0x0813c006 in strcpyrealloc (dest=0x0, src=0xb737fc44 "The Good Wife") at tools.c:117 #8 0x080d0adb in cEvent::SetTitle (this=0xb6485f00, Title=0xb737fc44 "The Good Wife") at epg.c:185 #9 0x080cda8a in cEIT::cEIT (this=0xb738022c, Schedules=0x81993e0, Source=1409286144, Tid=96 '`', Data=0xb7380338 "`\364@ \372\315 \370 \031#: aw;\331\320\022\065", OnlyRunningStatus=false) at eit.c:297 #10 0x080ce302 in cEitFilter::Process (this=0xb6443f20, Pid=638, Tid=44 ',', Data=0xb7380338 "`\364@ \372\315 \370 \031#: aw;\331\320\022\065", Length=1091) at eit.c:403 #11 0x0811e9bb in cSectionHandler::Action (this=0xb6444098) at sections.c:212 #12 0x08135ee5 in cThread::StartThread (Thread=0xb6444098) at thread.c:257 #13 0xb7fa0c39 in start_thread (arg=0xb7381b70) at pthread_create.c:304 #14 0xb7d0193e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (The only plugin loaded here is streamdev-server to give me a dummy output device.) The SEGV isn't always in the same place: I did originally think it was only when strcpyrealloc is called from cEvent::SetSeriesCRID but it seems to be from any call to strcpyrealloc at random. I've also seen it SEGV after calls to qsort. I'm a bit suspicious about the SEGV happening at a different place each time I run it. I suspected bad RAM and I did try running Memtest86+ last week but got no errors after a few mins run (when I've had RAM die in the past, it's always shown up pretty quickly in a Memtest86 run). I don't think it's two threads trying to use the same pointer but I could be wrong! Any thoughts? I think I'll just stick with the VPS Fallback stuff for now! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VPS fallback patch
On Monday 18 Jul 2011, Dave wrote: > For some time (at least since 2008) Mandriva Linux have been including > the attached patch in the version of vdr shipped with their > distribution. It allows timers to be triggered directly by the > Now/Next data in the EIT provided that a new parameter is set in the > config file. > > Looking back in the mailing list archives I see the question of > including this feature in vdr is an old one; see for example: > > http://www.linuxtv.org/pipermail/vdr/2005-August/003975.html > > 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. I will have to give your patch a go becuase I've recently missed a few recordings due to tennis and football over-running!! I presume I need to set timers with no margin at the start and with vps enabled for all for this to work? Do I also need your tvanytime patch for this to work? I did try it a few days back with vdr-1.7.19 but I kept on gettign seg faults from calls to strcpyrealloc! I was, however, in the process of sorting out some other issues at the time so will have to try it again now that I've fixed the other problems! :-) 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 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
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 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] 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
[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 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 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 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] Developer versions
On Wednesday 12 Jan 2011, Torgeir Veimo wrote: > On 12 January 2011 13:09, VDR User wrote: > > On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo wrote: > >> You can always try softdevice, which is mostly a playback interface > >> using ffmpeg. > > > > Isn't softdevice abandoned? > > It hasn't seen any new features added for a while, but should still > work as a software only playback device. Unfortunately, it does seem to have been abandoned. I'm still using it with vdr 1.7.0 (I've never managed to get it to work with any more recent versions, probably because it doesn't like the change to TS). I'm reading this (and similar threads) with interest: no HD in my area yet but it is meant to be coming this year. All of the current HD options seem to be a bit hit and miss so I've not really had a go at that yet. Softdevice uses libavcodec to decode and then a number of different methods to output the decoded frames. I'm using it with a Matrox card for output and this works really well. It's a nice, lightweight solution that doesn't depend on having an X server running but doesn't support a client- server setup. > > At any rate vdpau support is a requirement so anything > > > > that doesn't have it can automatically be ruled out. I do agree that > > it would be nice to have an ffmpeg-based vdr plugin but at present > > the only vdpau capable option I'm aware of depends on libxine. > > I guess that what you'd really want would be a pure VDPAU playback > device, not necessarily using ffmpeg. What would be nice is if the decoding functions in ffmpeg / libavcodec supported vdpau. I don't know whether that is even possible or whether it is only possible to decode "directly to HDMI", for example, and not just decode and then use something else to output the decoded frames. Maybe this is now possible: I've not looked at ffmpeg for a while, although my experiences of ffmpeg is that there are huge interface changes between releases that break things! 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 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] MythTV Adds Support For NVIDIA VDPAU
On Monday 01 Dec 2008, Torgeir Veimo wrote: > On 1 Dec 2008, at 21:49, Magnus Hörlin wrote: > > I have introduced VDR to at least 20 people (mostly windows-users) > > over the years, but this may be the day it ends. > > It appears you think that VDR will never get a plugin that can utilise > the VDPAU (or similar) api? I assume it could be incorporated into softdevice using a patched version of ffmpeg because that's what softdevice uses to do the actual decoding steps. Not looked into it, though. I don't have an nVidia card on my vdr box so I can't play about with this: no DVB-T HD stuff in the UK for several years to come so I'm happy using CPU grunt for MPEG2 decoding for now. 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 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] 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] 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] 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] 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] VDR on OpenWRT / embedded system
On Wednesday 27 February 2008 19:46:40 Artem Makhutov wrote: > Hi, > > has anybody thought of running VDR on OpenWRT? > > The Asus WL-500g Premium is an wlan access point with two USB 2.0 Ports. > It has a 266 MHz Broadcom BCM94704 MIPS CPU and is running linux. > > http://wiki.openwrt.org/OpenWrtDocs/Hardware/Asus/WL500GP > > It is possible to connect a harddrive and some USB DVB-S cards via USB > to the access point. > > So VDR has to be compiled for the MIPS architecture. > > The benefit of an access point is that it makes absolutly no noice, > is quite inexpensive and takes less electricity. > > It would be great if the access point could record videos on its harddisk > and share them over network via samba or stream it... > > Is this possible? Any ideas? Not exactly the same but I've had vdr running relatively successfully on a Linksys NSLU2, a.k.a. Slug, which was running Debian: http://en.wikipedia.org/wiki/NSLU2 These have got an Intel XScale processor running at 133 MHz (underclocked from 233 MHz) and a whole 32 MB of RAM (although it's possible to upgrade that with some dubious soldering...). I had a USB external disk and a USB DVB card on it and I used it as a backup system for when I went away. It worked reasonably well but the lack of RAM was a bit of an issue because it would occasionally randomly kill processes due to a lack of memory! Overall, it worked but there's no serial port (well, no external serial port: you can solder one on) so I couldn't get a LIRC remote detector on it. I can't remember if I tried the remote detector on the USB card: probably not because there's no video output so you wouldn't be able to see what you were doing, anyway! I've never managed to get more than one USB DVB device to work properly together for any length of time and a single DVB device would be restrictive. I was setting timers using a script which converted dates and times into SVDRP commands. There's also the MediaMVP which is a small (I think) MIPS system but that's designed for this sort of thing so maybe not as interesting! 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, 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] 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] Dual Tuner Cards (Nova-T 500)
On Monday 25 June 2007 11:57, Richard Lithvall wrote: > On 6/25/07, *Laz* <[EMAIL PROTECTED] > > >> I did read stuff a while back about people getting USB disconnects > >> from them at random but I've never seen that with mine. > > Andrew Herron wrote: > > Same here... no disconnects. > > Which kernel are you running on? I'm still on 2.6.20 and are > experiencing disconnects approx every 14 days... I haven't seen any > decent report on the DVB-mailinglist that this issue have been solved. I'm running a 2.6.20 kernel (I think I originally used the cvs DVB drivers for the card but I'm pretty sure they're now the stock kernel ones). As for disconnects, seeing as the USB devices are hard-wired, they shouldn't disconnect! I've got a couple of the external USB2 Nova-t devices and they go through phases of randomly doing a USB disconnect. Maybe it's down to luck whether your dual card disconnects or not (dodgy solder joints, or something?): I was a bit worried about this when I was buying mine but I've never seen this one disconnect. The remote sensor doesn't work but then I'm using a home-brew LIRC detector which I've found to work much better than the Hauppaugue (sp?!) detectors so the lack of remote sensor isn't an issue for me. I'd get another one if my Epia board had a second PCI slot! 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] New VDR hardware
On Wednesday 03 January 2007 21:44, Torgeir Veimo wrote: > On 3 Jan 2007, at 20:45, Kartsa wrote: > > Now that this came up. I was wondering in my earlier post today > > about twin tuner cards and if I understood correctly Nova-T 500 is > > such a card. And if I again understood correctly it works with > > linux and VDR? > > Some people including me are experiencing usb disconnection with the > nova-t 500 (it has an internal usb bus), which in some cases can make > your machine freeze, and in the best case causes you to loose a few > seconds of playback / recording. See the linux-dvb mailing list for > more details. Hmmm...I've got one of these and I've never seen it disconnect yet (a few months so far...fingers crossed!). When I've seen USB disconnections with two USB2 Nova-T devices, I was getting things like /dev/dvb/adapter0, /dev/dvb/adapter2, /dev/dvb/adapter3, i.e. adapter1 missing from where one of them had been originally before disconnecting and then being reassigned as adapter3! in this situation, vdr only sees the first DVB device because it starts at adapter0 and stops counting when the next number doesn't exist. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New VDR hardware
On Saturday 30 December 2006 19:53, Richard Scobie wrote: > Timothy D. Lenz wrote: > > Too bad it only has 1 expansion slot. That means only 1 tunner board. > > I wouldn't even concider anything with less then 2-3 slots. > > It does have 4 x USB 2.0 which seems to be becoming popular for tuners > now. Nice idea but... I've never managed to get two USB2 Nova-T devices working together for extended periods of time hanging off an Epia board. After a few hours, both of the USB boxes will randomly disconnect themselves leaving a very unhappy vdr because the DVB devices have disappeared form under its nose!! i did try various driver debugging options but never came to any conclusion about why they did this. Most of the time a reboot will restore them; other times, they need unplugging and a reboot so that they get the firmware reloaded. Maybe this is down to a buggy USB chip on the motherboard or maybe I'm just unlucky and for some reason my two USB devices won't play happily together (on their own, they can work seamlessly for weeks!), or maybe it's down to a firmware bug or something. I also have a Nova-T 500 which is a PCI card containing two USB DVB devices with an on-board USB controller: that works perfectly (in conjunction with one of the USB Nova-T devices!). Other USB devices might work well together, though... Just my experiences! My spare USB device is currently hanging off a Linksys NSLU2, a.k.a. Slug, but that's a story for another day! ;) Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev remote streaming control missong
On Wednesday 20 December 2006 10:31, Kartsa wrote: > Laz kirjoitti: > > I do this sort of thing by nfs mounting /video from the remote system > > on a subdirectory on the local system. Probably not the most elegant > > system because the empty directory gets deleted by vdr when the > > remote system isn't mounted so you might need to create it before > > mounting. > > > > The remote recordings appear in a sub-folder and so get sorted by > > date, rather than alphabetically because they are treated as series > > recordings. I'm doing the mounting and unmounting through > > commands.conf. > Well thats what I've been now putting up (since my last post). I was > just thinking how to get both the client and server recordings shown at > the same time and this is the solution for it :) Thanks. I was also > thinking to use the commands.conf. I was also thinking I'll try to > mount "over" the local recordings and thus get kind of swithing between > client and server recordings. But this is yet to be tried :) I thought about trying that but bear in mind that that would also replace the *.conf files (unless they are elsewhere) and the epg data. You'd have to restart vdr for the mounting. Another point to watch out for is you need to do a "touch /video/.update" to get vdr to acknowledge the mounted recordings. If you get the permissions right, you can delete and edit the remote recordings with no problems. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev remote streaming control missong
On Wednesday 20 December 2006 09:30, Kartsa wrote: > Btw. does it exist a plugin with what it would be possible to watch the > recordings of the remote vdr? I would prefer a plugin because my server > vdr has dvb-c cards and client vdr has dvb-t cards. This also means > that I have no antenna signal for the client (thats why its a client). > I want to have it as a vdr box because on summer time I take the client > with me on the cottage where I have dvb-t signal. This way I do not > need to make any changes to the box while I take it with me :) I do this sort of thing by nfs mounting /video from the remote system on a subdirectory on the local system. Probably not the most elegant system because the empty directory gets deleted by vdr when the remote system isn't mounted so you might need to create it before mounting. The remote recordings appear in a sub-folder and so get sorted by date, rather than alphabetically because they are treated as series recordings. I'm doing the mounting and unmounting through commands.conf. As I say, there's probably a better way of doing this but I have yet to find one! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdradmin: can't "watch tv"
On Monday 04 December 2006 13:45, Gavin Hamill wrote: > On Monday 04 December 2006 13:14, Suur Karu wrote: > > Installed vdradmin-am-3.5.1 give me strange TV picture on "Watch TV" > > menu: http://kodu.neti.ee/~pa000t/files/vdradmin.gif > > > > make.sh check said that all Perl modules presents. > > Using Slackware 11.0 (2.6.18 kernel) with 2 budget cards. > > VDRAdmin's 'watch TV' feature only works with Full-feature cards. It also works with a recentish CVS version of the softdevice plugin. Note that you must enable he GRAB command on the vdr command line. From man vdr: -g, --grab=dir Write images from the SVDRP command GRAB into the given direc- tory dir. dir must be the full path name of an existing direc- tory, without any "..", double '/' or symlinks. By default, or if -g- is given, grabbing images to disk is disabled. Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Remote plugin with Hauppauge Nova-T usb2
On Wednesday 25 October 2006 02:13, Laz wrote:
> Has anyone managed to get the built-in detector in a Hauppauge Nova-T usb2
> working with vdr with the remote plugin? I'm just swapping a Nova-T PCI
> card for a dual-tuner Nova-T 500. So far, it looks like the DVB part is
> working (not tested properly yet but I have 3 DVB devices) but I'm now
> tring to get a working remote again. I had been using a "new type"
> Hauppauge remote on the old PCI card through LIRC (after patching the CX88
> source for the keymap). I'm hoping that I can just use the
> /dev/input/eventX from the USB Nova device without fighting LIRC (the
> remote generates keypresses which makes using irrecord a nightmare!).
{snippage}
DOH! Finally sorted it: directfb was grabbing the input device before vdr
could get at it.
Adding "disable-module=linux_input" to /etc/directfb and it works. Well.
:)
Cheers,
Laz
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Remote plugin with Hauppauge Nova-T usb2
Has anyone managed to get the built-in detector in a Hauppauge Nova-T usb2 working with vdr with the remote plugin? I'm just swapping a Nova-T PCI card for a dual-tuner Nova-T 500. So far, it looks like the DVB part is working (not tested properly yet but I have 3 DVB devices) but I'm now tring to get a working remote again. I had been using a "new type" Hauppauge remote on the old PCI card through LIRC (after patching the CX88 source for the keymap). I'm hoping that I can just use the /dev/input/eventX from the USB Nova device without fighting LIRC (the remote generates keypresses which makes using irrecord a nightmare!). The USB remote device appears as /dev/input/event1: I: Bus=0003 Vendor=2040 Product=9301 Version= N: Name="IR-receiver inside an USB DVB receiver" P: Phys=usb-:00:10.3-1/ir0 S: Sysfs=/class/input/input1 H: Handlers=kbd event1 B: EV=3 B: KEY=afc302 2002805 0 0 0 4 18000 180 4801 9e1680 0 800200 ffc And should be accessible by the vdr user: crw-rw-r-- 1 root video 13, 65 Oct 24 22:16 event1 evtest seems to work correctly, i.e. lists the keys and all keys seem to give the correct named codes. When I run vdr with the remote plugin, I get the following relevant bits: Oct 25 01:45:00 vdr-tng vdr: [11605] device /dev/input/event1: IR-receiver inside an USB DVB receiver Oct 25 01:45:00 vdr-tng vdr: [11605] remote: using '/dev/input/event1' Oct 25 01:45:00 vdr-tng vdr: [11605] remote control softdevice-dfb - keys known Oct 25 01:45:00 vdr-tng vdr: [11605] remote control remote-event1 - learning key At this point, I see the OSD message about learning keys and it asks me to press the "Up" key. At this point, nothing happens! Pressing keys on the remote has no effect and it gets no further. As far as I can see, it all looks good until it gets to the actual remote plugin! Am I missing something simple here, or am I wasting my time and should go back to trying to get LIRC working with this device?! 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
Re: [vdr] Feature Request: MySQL interface for EPG/configuration
On Saturday 09 September 2006 12:09, Christian Wieninger wrote: > Rene Bartsch wrote: > > if the configuration (channels, transponders, options) and EPG would be > > stored in a MySQL-DB other applications could easily use that data > > instead of doing expensive scans of the files again and again. > > > > Maybe there could be a compiler switch or even a command-line option for > > VDR to switch between file and SQL mode. > > this could even solve some problems regarding synchronisation/thread > safeness. But IMHO this sounds like a feature of VDR 2.0 ;-) It does have the added overheads of running MySQL on what might be a low-power system, slower startup, etc. Then again, reading large amounts of EPG data, etc. from what can be huge flat files should improve things! Maybe it could be a build-time option... Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
