Re: [vdr] 1.7.12 w/ FF card on old Linux + S2API wrapper
On Sun, Jan 31, 2010 at 1:01 PM, Gavin Hamill g...@acentral.co.uk wrote: I've been using the same 1.4.7 setup for over 2 years and thought I'd dip my toe in the 1.7.x world. I'm using Ubuntu dapper (mid 2006) so my DVB kernel/header setup is still at API level 3, hence I've been using Udo Richter's S2API wrapper. While your system may work for years without updating it, eventually you will fall too far behind and either need to update everything or butcher the hell out of your source with patches that may or may not work properly. Lots of guys grumble about everything they need to update when they finally decide to get out of the dark ages, and I can never understand why they expect it to be any different. At some point, all the time effort wasted on backwards compatibility winds up only serving a very small handful of guys that seems to get joy from telling people how long it's been since they've updated their system. My motto is stay at least remotely current or get left in the dust. ;) If you're using a v4l tree that works with both your kernel and the S2API wrapper, then you may want to try a VDR version prior to the FF specific stuff being moved into a plugin and see if you have any better luck. I could be wrong but I think the FF change may not be 100% yet. Good luck! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR plugin options
On Sat, Jan 30, 2010 at 3:07 AM, Udo Richter udo_rich...@gmx.de wrote:
The correct way to place every array element as one parameter, without
doing any additional whitespace separation, is this:
$vdrbin -L $vdrlib ${vdrpl...@]}
In contrast, ${vdrplug[*]} merges all to one parameter, ${vdrpl...@]}
does another whitespace separation run.
runvdr extreme also uses a bash array for building the command line.
What makes that correct? Just sounds like a different (and more
complicated, ..I guess) way to accomplish the same end result, but no
more correct then using double/single quotes.
I'm no bash expert but STRING=$STRING -P'asdf arg' works equally as
well as ARRAY=( ${arr...@]} new item ) in my experience. What am
I missing?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Gather necessary options for build in Make.global and include it.
On Sat, Jan 30, 2010 at 4:21 AM, Udo Richter udo_rich...@gmx.de wrote: However, this is not a concern for VDR or for this patch. Its ok for VDR to look ahead, and not to carry endless compatibility hacks with it. I couldn't agree more. I cant stand when something is bloated down with that, just because some users out there refuse to update their system. I understand 'if its not broke, dont fix it', but that doesnt mean be an anchor weighing everything down. If you choose to stay in the dark ages, then suffer the consequences. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] frontend 0 timed out.... Was working fine last night.
On Sun, Jan 24, 2010 at 6:43 AM, Scott sc...@waye.co.uk wrote: Hi, Last night my system (DVB-S2 Hauppauge card/Liplianin driver/Kerner2.6.27.10 (64bit OpenSuse) /l vdr 1.7.9/xine-ui with vdpau) was working fine, but this morning I cannot watch TV and get these errors. It wasn't very windy last night, but I am wondering what the symptons are if the dish becomes misaligned, or the LNB fails? Unfortunately I don't have another receiver to test it. If the dish is not aligned you will not be able to get a lock. Unfortunately there's not a single answer to diagnose your problem, you'll have to use process of elimination to track down whats actually wrong. However, I would start with the easy stuff such as reload drivers, restart app, or reboot the pc before hassling with hardware. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR plugin options
Use double-quotes to surround your plugins and single-quotes for plugin options. For example: VDR=$vdrbin -L $vdrlib PLUGINS=-Pfemon -P'softdevice -vo xv:full -ao alsa:mixer:pcm=default' eval $VDR $PLUGINS ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Location of subtitles
Hi! (VDR version 1.7.10, Ubuntu 9.10) I have little problem with subtitles.. Location of them. My TV is FullHD and to get nice menus I have set: Setup - DVB Subtitle offset: 100 Setup - Plugins - xineliboutput - OSD Resolution: 1920x1080 Blending method: Hardware Scaling method: no Show all layers: no Dynamic transparency correction: Off Static transparency correction: Off External subtitle size: tiny DVB subtitle decoder: VDR Problem is that 100 is bigest offset value what can be set and with that value, subtitle are about middle of screen (at left side of course) and not at foot area where they should be. If I change Blending method to software, I can set subtitles to right place with offset 70, BUT then text at OSD is awful looking. -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine vdpau not working?
On Sat, Jan 9, 2010 at 12:16 PM, Simon Baxter linu...@nzbaxters.com wrote: Currently I only have SD content to watch and my Sony Bravia 32V only supports up to 1360x668. Any point using vdpau? If your system can play the content without it, no. VDPAU essentially provides playback on hardware that otherwise wouldn't be able to handle it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] genindex.c for vdr-1.7.x
2010/1/7 Reinhard Nissl rni...@gmx.de: Hi, Am 07.01.2010 22:09, schrieb Theunis Potgieter: I guess I will have to wait for the output device plugins to update before I can start using vdr-1.7.11. Thanks for pointing to the change log :) Regarding vdr-xine-0.9.3, please have a look at the attached patch. I can see VDR's osd but I don't get any audio/video for some reason. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Irritating bug watching ongoing recordings 1.7.10 (karmic builds)
On Tue, Jan 5, 2010 at 1:10 PM, Johan Andersson j...@jna.pp.se wrote: Have anyone else seen this problem? When I watch an ongoing recording vdr does not see it grow. Say I record a 60min episode and start to watch it 10min in. Pressing 'Ok' will show me that the recording is 10min in size. After 5min it still shows 10min size. If I stop watching and immidiately resume watching it, vdr will show 15min in size. If I let it continue till 15min it will stop my watching the recording as if it was ended. I can the of course resume watching again, as the size will always be the size when I start watching the recording. This sounds like a similar problem I've already reported, in which case Klaus is aware of it and has been working to fix it. Maybe he'll see this thread and elaborate further. It's nice to hear someone else reporting this bug as well so we know it's affecting other users. ___ 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 Mon, Jan 4, 2010 at 9:54 AM, Timothy D. Lenz tl...@vorgon.com wrote: I wish we could get away from xine. Too many layers. VDR/VDPAU/XINE/XORG. End up with lots of problems, change channels oo fast, somthing crashes, weak signal, something crashes, FF/RW speed changing sometimes crashes, with all the buffering, get slow channel change, slow responce to pause, RW/FF and lots of lip sync problems. Need to reduce some middle ware. Everyone seems to have their own experience. Not sure why you have so many problems but it doesn't seem very common. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 451 Grab image failed
On Sat, Dec 26, 2009 at 2:52 PM, Rene linu...@hertell.com wrote: Hi all! I have had problems in getting screen captures from VDR (VDR 1.6.0_p2-r3 on Gentoo) with with for example: svdrpsend.pl grab file.jpg Is there any more information in /var/log/syslog or is that the only message? Grab wasn't working for me but it was because I was using the xine plugin and didn't have a few necessary packages installed for grab to work. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
On Fri, Dec 25, 2009 at 1:21 PM, Theunis Potgieter theunis.potgie...@gmail.com wrote: What you could do is to make a boot process similar to most rescue or live-cd/usb. The idea is to make the whole thing run in ram, so boot by using network or memory stick, copy squashfs to ram and run from there. Should be lightning fast. Do you have a howto for this? I would like to give it a try myself. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Shutting a system down. (was: vdr shutdownskript - wrong time)
On Fri, Dec 25, 2009 at 1:24 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Donnerstag, den 24.12.2009, 20:00 -0800 schrieb VDR User: On Wed, Dec 23, 2009 at 5:55 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: At some point the shutdown mechanism apparently became rocket science and I decided to no longer touch it (especially since I don't even use it myself). ;) Personally I don't see any real reason to ever shut down/wakeup feature. Maybe that's useful for guys running VDR on laptops or old pc's that consume a lot of power(?). I only use VDR in my living room as my main tv/media source, and on a test box for messing around with but that's it. I don't actually watch tv on a computer monitor. Sorry, I do not get your reasoning. Do you mean if a system uses less than 5 – or a different number – watts it does not need to be shut down? Whether or not to shut it down is completely the decision of the user. But for example there might be some guys worried about running their laptop battery down so they prefer to shut it down. Or some guy who is really concerned with his power usage in general and wants everything off if he isn't using it. However, in my case since VDR is my main tv/media source, it would be annoying to have to boot the computer every time someone wanted to watch/listen to something, therefore the box stays on 24/7. Thus, never having use for shutting down. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel to Adapter mapping?
On Wed, Dec 16, 2009 at 3:03 PM, Calypso Cricket calypsocric...@gmail.com wrote: Hi All, Where does VDR maintain the adapter to channel mapping? Thanks. Unfortunately it doesn't support this feature. I wish it did however, believe me! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] US OTA ATSC - Does it work?
On Sun, Dec 13, 2009 at 12:11 PM, Calypso Cricket calypsocric...@gmail.com wrote: Hello, I have been banging my head on trying to get my two ATSC cards to show content in VDR. I have applied the patch (http://www.fepg.org/patches/vdr-1.7.2-atsc-0.0.3.diff) and also the plugin found here: http://www.fepg.org/atscepgReadMe.html However, the plugin does not lock onto any channels. I am able to use 'scan' and 'w_scan'. However, these scan tools does not seem to produce the correct channels.conf file format. If anyone has made US OTA ATSC work, please provide some guidance. Thank you. I know a few people who have been struggling with VDR+ATSC for quite a while. I've wanted to give it a go myself but not if it's a constant fight/hassle to have it running. Hopefully ATSC support will become a part of vanilla VDR at some point but I honestly don't think that's very high on the priority list. Doesn't hurt to ask however! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] aspect ratio/videolength in vdr-1.7.10
On Wed, Dec 9, 2009 at 10:58 AM, Tony Houghton h...@realh.co.uk wrote: On Sat, 5 Dec 2009 21:34:42 +0100 Halim Sahin halim.sa...@t-online.de wrote: How can I determine that from a vdr-1.7.10 recording? Unfortunately vdrsync doesn't work any more :-(. I don't know how you could find the length; maybe it's a simple calculation from the size of the index.vdr file? If the recordings store PCR, you could just read the first and last PCR and do some quick math? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] aspect ratio/videolength in vdr-1.7.10
On Wed, Dec 9, 2009 at 1:32 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 09.12.2009 20:13, Halim Sahin wrote: Hi VDR User, On Mi, Dez 09, 2009 at 11:03:33 -0800, VDR User wrote: On Wed, Dec 9, 2009 at 10:58 AM, Tony Houghton h...@realh.co.uk wrote: On Sat, 5 Dec 2009 21:34:42 +0100 Halim Sahin halim.sa...@t-online.de wrote: How can I determine that from a vdr-1.7.10 recording? Unfortunately vdrsync doesn't work any more :-(. I don't know how you could find the length; maybe it's a simple calculation from the size of the index.vdr file? If the recordings store PCR, you could just read the first and last PCR and do some quick math? Does vdr store the pcr? No, it doesn't. You can take the size of the index file, divide it by 8 and you get the number of frames in the recording. The info file tells you the number of frames per second (at least with newer TS recordings). That makes it pretty easy! :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdpau setup steps for vdr client
On Thu, Dec 3, 2009 at 10:44 AM, Simon Baxter linu...@nzbaxters.com wrote: To be fair to my comment above, I've had audio sync problems with live TV on all versions above vdr-xine-0.8.0 which is why I've never been able to run a newer version in production. I've had several posts on this and tried everything anyone has suggested - but after an hour or my wife banging on about the poor quality, always downgrade back to VDR-1.6.0 and VDR-XINE-0.8.0 So I don't think my problems are related to VDPAU or VDR-1.7.x. Maybe your problem is an outdated alsa or something like that? I use vdpau with vdr-1.7.10 and xine-0.9.3 with no sync problems. I also didn't have to edit ~/.xine/config as the default settings worked fine. I agree your issues are elsewhere then vdr or vdpau. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Odd filesystem errors (Theunis Potgieter)
On Mon, Nov 23, 2009 at 10:17 AM, HighlyCaffeinated javatod...@yahoo.com wrote: I have. e2fsck ran against the (unmounted) volume and found no errors. I've never experienced something like this before and to be honest would not believe it if I hadn't seen it. I have successfully copied the sub-directories and data across the network using Windows/Samba, then copied it back to a new folder name. Both played perfectly. I just can't get rid of the original directories. I had something similar happen a long time ago. I can't quite remember how exactly but I had to do something weird to be able to delete the directories. I can at least tell you that I found the answer by googling. Good luck. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.10
Greetings Klaus. Thanks for the new version! It seems the ffwd/rew crash on certain HDTV recordings is now fixed so thats great news! However, the problem still exists where if I start replaying a recording while it's still recording, the length increases very quickly to ridiculous numbers. The replay stops at the point in the recording which I started playback. If I delete the index file and have VDR generate a new one, I still get the crazy recording length and the audio/video is out of sync. Maybe VDR should not actually start playback until after the new index file is generated? Although that won't fix the problem of starting playback before the recording has finished. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [path] vdr-1.6 better spu on ff card
Did you know Klaus is updating the OSD to 24bit truecolor? I don't think he is going to adapt 1.6.x further though so you might need at least 1.7.10(?) to use it. Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] livebuffer patch improvements suggestions.
On Thu, Nov 19, 2009 at 10:26 AM, Tommi Lundell prel...@kapsi.fi wrote: 2) Patch only record current channel. It would be nice if i can select channels from lists where buffers are active. Example. i change channel and noticing that program what i want to look is already running so i simply press jump backward button and start to look program from beginning. (2GB can keep about 100 minutes in buffers. If i select 5 different channels that i got 20mins buffer in every channel) But point 2) is more complicated and my skills don't go even close what implementation needs. Is that even possible to implement directly into VDR or with patches? To buffer any channel, a dvb device must be locked to the same sat transponder the channel is on. If you want to always buffer 5 channels, and 4 of them are on different transponders, you would need to have 5 dvb devices installed to watch live tv. 4 devices dedicated to those transponders and 1 available to surf any channels of live tv. I can't honestly see the benefit of this over just setting timers to record your favorite shows. It seems like a lot of work hardware for something that there are better solutions for imo. Maybe you watch an unusually large amount of tv without every checking the guide for future shows that might interest you? ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] livebuffer patch improvements suggestions.
On Wed, Nov 18, 2009 at 8:46 AM, Tommi Lundell prel...@kapsi.fi wrote: Hello. 1) RAM is cheap now days. Can I use RAM to keep buffer data? (System running from USB stick so only reason to start Hard Disk is when i use recordings) 2) Patch only record current channel. It would be nice if i can select channels from lists where buffers are active. Example. i change channel and noticing that program what i want to look is already running so i simply press jump backward button and start to look program from beginning. (2GB can keep about 100 minutes in buffers. If i select 5 different channels that i got 20mins buffer in every channel) There was some talk a while back about implementing a live tv buffer into VDR. Many users don't like the idea of their harddrive recording 24/7 so it was mentioned to be able to buffer to ram just as you're asking about. I personally do NOT want to buffer to harddrive, especially non-stop. However, I'm all for buffering to RAM since it _is_ very cheap these days for 2-4GB. I don't know how much of a priority this is to Klaus but I'd recommend searching the mailing list for that thread because he did participate in the discussion. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] livebuffer patch improvements suggestions.
On Wed, Nov 18, 2009 at 11:13 AM, Timothy D. Lenz tl...@vorgon.com wrote: Wouldn't work very well with HD video. Our locals (ATSC) use 8-13Gb/hour VDR User wrote: On Wed, Nov 18, 2009 at 8:46 AM, Tommi Lundell prel...@kapsi.fi wrote: Hello. 1) RAM is cheap now days. Can I use RAM to keep buffer data? (System running from USB stick so only reason to start Hard Disk is when i use recordings) 2) Patch only record current channel. It would be nice if i can select channels from lists where buffers are active. Example. i change channel and noticing that program what i want to look is already running so i simply press jump backward button and start to look program from beginning. (2GB can keep about 100 minutes in buffers. If i select 5 different channels that i got 20mins buffer in every channel) There was some talk a while back about implementing a live tv buffer into VDR. Many users don't like the idea of their harddrive recording 24/7 so it was mentioned to be able to buffer to ram just as you're asking about. I personally do NOT want to buffer to harddrive, especially non-stop. However, I'm all for buffering to RAM since it _is_ very cheap these days for 2-4GB. I don't know how much of a priority this is to Klaus but I'd recommend searching the mailing list for that thread because he did participate in the discussion. On the contrary 2-4GB should be just fine for typical live buffering use. If you want an hour worth of HDTV buffering you're probably better off setting timers to record the shows you want but regardless you can just add more ram to support more buffering time. Btw, I have several hour-long HDTV recordings and none of them go over 3GB. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
On Fri, Oct 30, 2009 at 12:11 AM, Theunis Potgieter theunis.potgie...@gmail.com wrote: Does the sourcecap patch not address this whole issue? Even if source cap or something similar is applied, how will VDR be able to tune to a 8psk turbo-fec type channel if v4l2 does not provide any support for it? It shouldn't be VDR's responsibility surely? unless 8psk turbo-fec becomes part of the new dvb-plugin archtitecture of future VDR. Turbo fec isn't specified in the stream or in v4l, it's only reported as 8psk. I may be wrong but doesn't sourcecaps only assign devices to orbital positions? What happens about all the orbital positions that contain both qpsk and 8psk turbo? It was suggested that you make a fake orbital position for those with 8psk turbo transponders, then change your channels.conf sources.conf accordingly. Consider the following: dvb devices being used: budget dvb-s, genpix dvb-s (supporting turbo fec), twinhan dvb-s/s2 sat1 tp1 (qpsk) dvb-s sat1 tp2 (8psk turbo) dvb-s sat2 tp1 (qpsk) dvb-s sat2 tp2 (8psk turbo) dvb-s sat2 tp3 (qpsk) dvb-s sat3 tp1 (8psk) dvb-s2 If you say sat1 should use the genpix because it has an 8psk turbo fec tp then you restrict the budget and twinhan ability to tune the qpsk on tp1. Same for sat2. If you want to tune sat3 tp1 by asking the devices 'are you s2 capable?' then you get a false hit by the genpix, which lies about being s2 capable (so it can provide 8psk). If you use sourcecaps and create a fake orbital position for sat1 tp2 and sat2 tp2 then it works but requires the user to create fake data and do more work. You can see simply doing a capability query is not good enough because it can return unreliable results. This isn't VDR's fault, it's v4l drivers but it can still be easily addressed within VDR which giving the user other advantages such as assigning certain devices to certain channels/transponders because they (maintain) lock better. Now consider you just simply add support for an optional file called override.conf (or whatever). This file could look like this: channel:list of devices to use 100:1,3 means for channel 100 use only devices 1 and 3. 101:2 means for channel 101 use only device 2. You could also add support for orbital positions with: orbpos:list of devices to use S100.0:2,3 means for orbital position S100.0 use only devices 2 and 3. S109.0:3 means for orbital position S109.0 use only device 3. So you see, simply doing a capability query is not enough because it can be unreliable. Using sourcecaps can solve the problem but requires non-existent orbital positions to be created and maintained in both channels.conf and sources.conf. By adding an override.conf, you can give full control to the user by using one simple _optional_ file. This seems like the easiest best with the most flexibility for the user. It solves _everyones_ needs and doesn't require false data, patching, etc. As mentioned before you can also write a simple shell script to auto-generate the override.conf for you. I know Klaus doesn't like to add files but if the file is optional and adding support for it means satisfying everyones needs, I can't see a good argument against it. Especially when the alternative requires at least some users to add fake data in their channels.conf+sources.conf. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
On Thu, Oct 29, 2009 at 1:13 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 10/28/09 23:15, Petri Helin wrote: Hi, I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi box), which works very well with the current Linux driver excluding channels with QAM-256 modulation. Would it be easy to check FE_CAN_QAM_256 in vdr before trying to use a device to tune to a particular channel? In such a case I could deactivate FE_CAN_QAM_256 in the drivers. I am using VDR 1.7.9, if it makes a difference. Checking the frontend capabilities is certainly the right thing to do, and I will see that this gets implemented. This still doesn't resolve a major problem for North Americans. The situation is that the 2 biggest dvb-s providers use a modified modulation, 8psk turbo-fec. There is only one device that is capable of tuning this but unfortunately the device has to pretend to be a dvb-s2 device to do so. Apparently the v4l guys (from what I was told) didn't want to allow 8psk turbo-fec in dvb-s because it's a non-standard modulation. So the problem becomes that VDR sees a dvb-s stream and the frontend of say a nexus-s will say its capable of receiving it, even though that dvb-s stream may contain the 8psk turbo-fec which a nexus-s can not tune. I believe the best way to handle this situation is by allowing the user control over what devices may be used to tune what channels. VDR can't be smart enough to figure it out due to incorrect bad design in v4l. Another strong reason to allow this to be configured at the user-level is what if the the user has 2 devices...both able to tune a channel but the signal is weak. Tuner 1 can tune it fine but tuner 2 has problems because of the weak signal. VDR is simply going to ask a free tuner 'can you tune this?', whereas the best scenario would be for the user to say 'use tuner 1 for this channel'. I can think of two ways to better deal with this; adding a new field in channels.conf, adding a tuneroverride.conf By adding a new field.. If the value is * then it means any device may tune it. If its an integer, then the values listed represent which devices should be used. For example: :*: use any device :2,3: use only device 2 or device 3 By using a tuneroverride.conf you can specify which devices to use with certain channels. If the channel isn't contained in tuneroverride.conf then VDR just uses it's own logic to figure it out (the capability check). The good thing about this method is you can create a simple shell script to auto-generate the tuneroverride.conf file using key indicators in the channels.conf... The file structure would be very simple: channel #:device,device,device,etc This is really the only way to satisfy _everyones needs_, by ultimately allowing the user to control device priorities. PLEASE take this into serious consideration as it's been a long standing problem that's only getting worse with more and more transponders move to 8psk turbo-fec. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
I have 3 dvb-s cards in one of my boxes. 2 of those cards are able to tune all channels in my channels.conf. 1 of them can only tune some. So, the problem is there seems to be no way to specify something like 'use device X,Y,Z' for a certain channel in channels.conf... I had raised this issue before but it seems there's no plans to address the issue. Big problem for users in this situation. I'm constantly losing recordings because of this as well. :( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How about implementing truecolor in VDR?
On Tue, Oct 27, 2009 at 6:29 AM, Александр a.g.pro...@tochka.ru wrote: Anybody working on it? IIRC Klaus had already started working on updating VDR's osd to support truecolor. I think he was trying to iron out some issues regarding high resolution with high color scenarios. Further, I recall discussions about vdpau being able to assist in drawing those osd's if it's available. There's a lot of user interest in this osd upgrade so hopefully it's still on the priority list. Someone told me Klaus sold his company so I'm sure he's just been busy with that if so. Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 plugin compilation error
On Tue, Oct 27, 2009 at 9:10 AM, Damien Bally bir...@free.fr wrote: Hello Compilation of dxr3plugin fails (vdr 1.6.0 slackware 13 kernel 2.6.29.6): make[1]: Entering directory `/home/vdruser/vdr-1.6.0/PLUGINS/src/dxr3-0.2.9' g++ -O2 -Wall -Woverloaded-virtual -c -DPLUGIN_NAME_I18N='dxr3' -D_GNU_SOURCE -DMICROCODE=\/lib/firmware/em8300.bin\ -DUSE_XINE_SCALER -I../../../include -I/usr/local/include -I/usr/local/include/libavcodec -I/usr/include dxr3interface.c In file included from dxr3interface.c:27: /usr/include/linux/dvb/audio.h:79: error: 'uint16_t' does not name a type dxr3interface.c: In member function 'void cDxr3Interface::SetAspectRatio(uint32_t)': dxr3interface.c:451: warning: unused variable 'wssmode' make[1]: *** [dxr3interface.o] Error 1 I've been googling with that but found nothing. What's wrong ? Try this patch: --- vdr-1.7.5/vdr.c.orig2009-04-12 11:05:51.0 -0700 +++ vdr-1.7.5/vdr.c 2009-04-12 11:07:08.0 -0700 @@ -32,6 +32,7 @@ #include pwd.h #include signal.h #include stdlib.h +#include linux/types.h #include sys/capability.h #include sys/prctl.h #include termios.h ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR can no longer be compiled with the current driver from http://linuxtv.org/hg/v4l-dvb.
On Wed, Oct 21, 2009 at 3:25 PM, Carsten Koch carstenkochelsd...@web.de wrote: The driver had its API version changed on 2009-10-19 17:08:05: I already emailed Klaus about this the other day so I'm assuming he's aware of it by now. In the mean time you can easily fix the problem by hand by removing the API minor version check. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Switching from MythTV to VDR
On Wed, Oct 14, 2009 at 7:04 AM, Andre Newman v...@dinkum.org.uk wrote: I'm looking for some pointers on VDR coming from a MythTV history. I'm happy with most of the MythTV features but not the stability or the playback image quality, I've been using MythTV as my only TV recorder for some years. Congratulations on finally UPGRADING your tv software!! ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine 0.9.3 audio problems
On Sat, Oct 3, 2009 at 12:52 PM, Simon Baxter linu...@nzbaxters.com wrote: I've been playing around with these values and have discovered the following (I only have SD channels - none HD) when replaying recordings. Setting engine.buffers.audio_num_buffers to 2300 (10x default) does help with the skips in audio - where under the default value (230) I intermittantly get 2-3 second jumps in audio. #engine.buffers.video_num_buffers is left at the default of 500. If I set this any higher, fast forwarding or rewinding causes the video to jump about 90 seconds. engine.buffers.video_num_frames (default 15) I've had to set to 60. Anything less than this seems to make the video jump 2-3 seconds, in line with the audio_num_buffers described above. With this set to 60, there's no lost audio but video/audio still gets out of sync, and it gets worse and worse for 20 seconds then the audio stops and the video catches up. Also with anything 60, I get on the vdr console when replaying recordings. What video card/driver do you use? I know of another guy with similar problems but with my Nvidia 8400GS using vdpau it works fine with just default settings. I've never had to adjust anything. Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Thu, Oct 1, 2009 at 9:03 AM, Theunis Potgieter theunis.potgie...@gmail.com wrote: Which gentoo overlay are you using for vdpau enabled xine-lib? I assume you need xine-lib-1.2 and vdr-xine or vdr-xineliboutput with vdpau enabled? Which driver version of nvidia do you require and which version of Xorg and xcb? I use Debian, not Gentoo. I'm sure there's some Gentoo guys here who can answer your questions though. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] femon plugin doesn't work ERROR (femonosd.c, 504): Function not implemented
On Wed, Sep 16, 2009 at 3:58 AM, Theunis Potgieter theunis.potgie...@gmail.com wrote: Would you care to write such a patch for vdr? In a way that Klaus could simply include in future releases. I think it would help a lot for end-users, trying figure out what possible causes are. I agree. Detailed error messages are the only ones worth printing/logging, especially when it comes to end-users trying to figure out why their box isn't working properly. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Loosing tuners
I found a problem which might be related in some way, dunno. I have 3 tuners and noticed that if I have 3 timers which overlap at all, and 2 of those timers are on the same channel, VDR still uses all 3 tuners instead of grouping the timers that are on the same channel together. I reported this to Klaus already but not sure if he's found the problem and/or worked out a fix for it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] timer set in a different channel than current
Please test your problem with vanilla VDR. If the bug persists then it's likely in VDR and not your patch. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] known user base (was: Re: Replay Problems with Extension HD)
On Wed, Sep 9, 2009 at 12:10 AM, Christian Tramnitzchris@gmx.net wrote: I don't think people would like that. DRBD has imho a good approach* to track users (and used versions!), but regardless of the method, this is certainly not on Klaus' priority list. Best regards, Christian (#68) *On first startup (or after upgrades) a unique ID will generated and the user will be asked if he wants to send this ID together with the current version to the maintainer. Optionally (to appear on a list just like vdr's user list) personal data may be entered, but this is up to the user. Pressing enter will just send the unique ID and version, aborting the prompt will not send anything. jori.hamalai...@teliasonera.com wrote: Perhaps VDR should try to send UDP packet to Klaus's server when it starts. Not all will not like it, but it is same for me. Windows software do this constantly under name for automatically check for program updates. BR, Jori, a registered VDR user since 2003. User-tracking has _absolutely no place_ in VDR what-so-ever!! It serves no purpose and if someone wants to be added to a user list somewhere, they can register themselves. If someone really thinks this is a brilliant idea, they can write a plugin to do it but it should have no chance becoming a part of VDR core. No offense but that's the worst idea I've heard by far. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
It's the exact same situation for North American users as well. You guys grossly underestimate our numbers since you're not members of that particular community. Klaus advertising his list of users, or the mailing list, or forums that are primarily non-english won't do much in terms of getting people to go to those places. I personally know a lot of guys who are aware of this mailing list and still don't bother to subscribe to it for one reason or another. Instead they prefer to wait for things to filter down to the resources they use. I know part of this has to do with the lack of support for NTSC because none of the developers use it. Even I pursued trying to get things that are hardcoded PAL to be either auto-detected or set by the user but there was basically no interest in response. I'm glad to be here personally and take an active role in helping any way I can in general because I think VDR is a great piece of software and only want to see it get better, broaden it's support features, and become the undeniable king of linux dvb hands-down. To the original poster, sorry that we've gone off-topic. I'm not sure how much of this actually has anything to do with replay problems with extension hd. ;) Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Mon, Sep 7, 2009 at 5:41 AM, Falk Spitzbergp...@spitzberg.de wrote: I'm also interested to see this information. Wouldn't it be good idea to publish it on the list, it would be more useful for the people who are looking for the information =) Let me see if it works for Klaus. Once he has his eHD running using the stuff that I've collected, i'll publish it either here or in the VDR portal. I'd suggest posting to the mailing list or both as VDR Portal caters 99% to people who speak german and isn't much help for the very large english-speaking-only VDR community. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Mon, Sep 7, 2009 at 9:14 AM, Petri Helinphe...@googlemail.com wrote: On Mon, Sep 7, 2009 at 6:57 PM, VDR Useruser@gmail.com wrote: I'd suggest posting to the mailing list or both as VDR Portal caters 99% to people who speak german and isn't much help for the very large english-speaking-only VDR community. I wouldn't say the english-speaking-only VD community is that large: At least if you look at the registered users: http://www.cadsoft.de/cgi-bin/vdr-counter.pl?action=statist I know for a fact it's large because I'm a member of that community and talk with many of them. Only a small portion of VDR users in general subscribe to this mailing list, the 'registered users' list, etc. from what I've seen. Perhaps you meant the great non-german-speaking community, who communicate in English? ;) Nope, I mean english-speaking-only. Like the other user pointed out, many many people are using various howto's and IRC for their VDR info, and never find their way here other places. I can't count how many times people have said they've never even looked at the MANUAL, README, and so on. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Sat, Sep 5, 2009 at 6:24 AM, Lauri Tischlerl...@iki.fi wrote: Somewhat related question is, is there some solution to have HD-VDR without X, other than eHD ? Not that I'm aware of but by no means have I researched that question in depth. ;) All this hullaballoo with vdpau/X/xine etc.. is somehow stupid if all you want is HD-STB. I'm not sure why you think vdpau is stupid if you want an HD stb. Using vdpau gives you the ability to have HD on systems that normally wouldn't have a chance at all, and it provides this at a very lost cost. The cheapest I've paid so far is $20 ($30-$10 MIR) for an 8400GS pci-e. So for a mere $30 on average, your old system that couldn't handle HD now can. Stupid is the last thing I would describe that as. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Sat, Sep 5, 2009 at 8:26 AM, Gavin Hamillg...@acentral.co.uk wrote: I'm not sure why you think vdpau is stupid if you want an HD stb. Using vdpau gives you the ability to have HD on systems that normally wouldn't have a chance at all, and it provides this at a very lost cost. The cheapest I've paid so far is $20 ($30-$10 MIR) for an 8400GS pci-e. So for a mere $30 on average, your old system that couldn't handle HD now can. Stupid is the last thing I would describe that as. Hm, I'd be happy to pay $150-200 for a hardware output card, similar to the good old FF technotrend cards, if it could save me hours of messing around with SVN bleeding edge code and trying to run exotic deinterlace filters :) I think there's a misconception about using vdpau. While there are a small few who have problems (as is the case with any software/hardware), most users are able to get vdpau working with little or no hassle at all. For me it takes 1min to download xine-vdpau, 7 minutes to compile it, 1min to download xine-ui cvs, 1min to compile it. Nvidia drivers take about 2mins to download and 1min to install. Less then 15 minutes _no patching_ is all it takes. Actually there is one patch come to think of it since I use xine-lib 1.1 instead of 1.2, it's xine-0.9.3/patches/xine-lib.patch... In any case it's never taken hours of time. Been really straight forward and simple for the most part. When I bought my first nexus-s, I bought it for the exact reason you mentioned. Wanted a simple fast solution that didn't involve much (or any) work on the linux side since I'd never used linux before. And at the time a nexus was also cheaper then building a new pc. However, those days are gone. You're willing to pay $150-$200 for a dedicated card that does only one thing. I recently paid $130 total for an Nvidia Ion system that will become my completely silent and fanless main HDTV VDR box that's about the size of a Nintendo Wii. That's where the market is going. You'll see less and less dedicated cards (especially FF DVB cards) because the cost to produce them is too high and the market for such a product too small. There's no profit to be made. That's a conversation for a different thread however. ;) I think that's what Lauri is getting at - the statement 'vdpau is stupid' is perhaps a little inflammatory, but there must be more time-efficient ways (other than the eHD card which is now hard to obtain) It sounds like the eHD is the most expensive solution in all areas; time, money, patching, etc. Whereas, vdpau seems to be at the other end of the spectrum being the least expensive, easiest, and so on. I've got 3 boxes running vdpau, all with different hardware and my experience has been the same with each setup.. It was a piece of cake and took almost no time to get going. Now I guess it's the guy who had a horrible experience turn to tell his story. ;) Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Thu, Sep 3, 2009 at 11:55 PM, Falk Spitzbergp...@spitzberg.de wrote: I don't know. But what is wrong about my attempt to find out what VDR does different during replay vs. live TV. I did never say that VDR does something wrong. I just asked a question. Too bad that nobody can answer it. All I'm saying is you seem to have a hardware problem that should be addressed @ the vendors customer service/product support. Have you even bothered to contact them? Maybe there's already a fix/solution waiting for you there. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Thu, Sep 3, 2009 at 3:10 AM, Falk Spitzbergp...@spitzberg.de wrote: Am Mittwoch, den 02.09.2009, 08:49 -0700 schrieb VDR User: Sounds like your question is more appropriate for the vendors customer support of that product. Definitly not, because my question ist only about the VDR core. I am just trying to find out what VDR does different when it transfers data to a device in live TV compared to replay from disk. That's completely independent from any device that's in use. Maybe that the eHD card is the only output device that crashes on VDR TS replays. How do you know the problem isn't a bug in the eHD driver or stream parser/decoder? An example I'll give you is vdpau. Certain things caused problems/crashes, but it was the fault of the driver and had to be addressed by Nvidia. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
Sounds like your question is more appropriate for the vendors customer support of that product. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Sun, Aug 23, 2009 at 11:24 PM, Lauri Tischlerl...@iki.fi wrote: Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;) That's nice but my main problem with vdr is having two televisions + one computer that can be used for TV watching too. HD UI is not the main driver for me. There really should be a proper server/client(s) architecture with vdr. Possible HD UI development for vdr to be useful should be developed to operate as IP streaming client. I really do not understand the rage about HD OSD and/or skins. VDR is meant for watching TV-programs, like sports, movies, documents, and porno, not OSD. Many of us are using real tv's and not computer monitors for viewing. And of course many are now doing hdtv. It's likely you're not a user of either or both of those. Certainly an HD OSD isn't required to watch tv but if you knew how ass ugly it was to see the crappy low-res 8bit OSD on a big high definition tv, you'd understand. Consider the HD OSD like having real nice woodgrain trim in your car. It's not required to drive but damn sure makes your car look better. Something else you might not have considered is that it really is necessary to have a flexible OSD these days when you have tons of users both with SD HD...Their display device capable of say 1920x1080 but the current OSD implementation not allowing you the full resolution when you're tuned to an SD channel. If you're going to update it to accommodate current/future needs, why not improve the OSD as a whole? There's no law that says VDR has to be stuck in the stone age.. It really can be slim trim, stable, and provide users with luxury as well. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Mon, Aug 24, 2009 at 3:57 AM, Lauri Tischlerl...@iki.fi wrote: I really wouldnt care less, if the OSD on my Toshiba 42 FullHD looks ass ugly, so be it, just about anything, while developing VDR, is more important then HD OSD. Real nice woodgrain trim in cars was used in some 1950's stationwagons. :) While I would place other things higher on the TODO list (well-designed server/client capability for example), a nice HD OSD wouldn't be at the bottom. I'm glad Klaus took notice of how many users wanted this. Keep in mind, that's why VDR even has HD support now, and probably TS as well because from previous postings he didn't show much interest since those wern't things he needed. But it's made the user base happy! Overall I'm for anything that improves/enhances VDR, and attracts more users in. If that's a fancy OSD or something else, it's all fine by me. I stand by my earlier statement that VDR can be slim trim, stable, and provide users with luxury as well because I think it's foolish not to believe that. Some people like peas carrots, some don't. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1.7.9 patches
On Mon, Aug 24, 2009 at 2:57 PM, Marcel Wittebaltasa...@web.de wrote: Goga777 schrieb am Montag 24 August 2009: Thanks for the ttxtsubs patch for vdr 1.7.9 Anybody has a vdr-1.7.9_extensions.diff patch? Or a setup plugin patch for vdr 1.7.9 have a look here please http://www.forum.free-x.de/wbb/index.php?page=ThreadpostID=7872#post7872 Has anybody tested this patch? Or does anybody know that's about the original extensions-patch from zulu? Is there an archive somewhere of all the patches that make up the extentions mega-patch (for lack of a better term)? I absolutely hate when patches are grouped together like that when I only want a couple features but forced to have 20 other things that are useless or I don't want. And it's not always so easy to just rip out the patches you actually want since difference patches can overlap in the source code. :\ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Sun, Aug 23, 2009 at 1:46 AM, Seppo Ingalsuoseppo.ingal...@iki.fi wrote: Othervise xbmc-vdr looks very promising with totally new high definition UI. Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.9
I have to use the following patch: --- vdr-1.7.5/vdr.c.orig2009-04-12 11:05:51.0 -0700 +++ vdr-1.7.5/vdr.c 2009-04-12 11:07:08.0 -0700 @@ -32,6 +32,7 @@ #include pwd.h #include signal.h #include stdlib.h +#include linux/types.h #include sys/capability.h #include sys/prctl.h #include termios.h ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.9
On Sun, Aug 23, 2009 at 12:07 PM, Goga777goga...@bk.ru wrote: I did so exactly in my previous mail PS vdr 178 compiled fine with existing headers Have you tried the patch I posted? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.9
On Sun, Aug 23, 2009 at 12:26 PM, Goga777goga...@bk.ru wrote: Have you tried the patch I posted? no, because I have already solved this problem (as I wrote in my previous mail) I could compile vdr 179 after of adding in dvbdevice.h string like typedef unsigned char __u8; It would be nice if you did so others with the same problem can see the result. Otherwise what's the point? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Turn off/relocate ts error logging
On Sat, Aug 22, 2009 at 10:12 AM, Timothy D. Lenztl...@vorgon.com wrote: My log files get so big it,s very hard to check them because of the ts error messages that get flooded to it. I've had logs near 2gb in size. I have a problem with xine crashing when there is a weak signal and the ts loging bloating the log files is creating a lot of problems. Need a way to turn off ts error loging or relocate to another file. You can use logrotate to limit the size of the log file. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
2009/8/20 Magnus Hörlin mag...@alefors.se: Yes, it has limitations but given the low power consumption it's still impressive. The ION runs fine with advanced deinterlacer for 576i and temporal for 1080i. A 9500GT can do advanced on 1080i but for me it's not worth the extra heat and space. I have the computer on the back of my TV. http://www.minhembio.com/magho You have the setup I'm looking to get soon. I want to be able to transmit video + 7.1 sound over HDMI, do you know if your ION can do this? From the screenshots I've seen, the difference between temporal and spatial-temporal deinterlacing isn't enough to warrant using a regular size pc (which I have now sitting behind my tv) over the much much smaller power not-hungry ION. Temporal should suit my wants just fine. -Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
I too have tried mythtv and found it to be a big bloated slow piece of crap. It seems to be a bunch of odds ends slapped together rather then a solid dvb app built from the ground up. Not impressed with it at all. I should note that even though I did give it a try, I never intended to replace VDR with it regardless of the test results. I am a VDR loyalist. :) Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xbmc-pvr (was - HD clients for vdr)
On Thu, Aug 20, 2009 at 12:37 PM, Morfstamorf...@gmail.com wrote: On Thu, Aug 20, 2009 at 7:55 PM, VDR Useruser@gmail.com wrote: I should note that even though I did give it a try, I never intended to replace VDR with it regardless of the test results. I am a VDR loyalist. :) I too have tried Myth on a number of occasions and have found it unwieldy and slow, not sure why its so popular, perhaps because of the flashier interface. That's definitely is a part of it. I know former VDR users who switched to myth for that very reason. Now that VDR has support for hdtv, it's finally getting an osd overhaul as well (maybe coming in 1.7.9?), which will be 24bit iirc. We'll finally be able to have a high color/high resolution osd as well, which I'm hoping will spawn peoples interest in making some really great skins and so on. Most tv stations it seems offer their logos in high color/high res as well. I know Klaus prefers to focus more on stability then things like candy enhancements but I think he realized this is something users really wanted to see implemented now that hdtv support is present. And with so many users investing in things like inexpensive vdpau-supported video cards over overly expensive 'full featured' dedicated cards, it's a logical enhancement to make to bring VDR up-to-speed visually. One thing I would like to see in the future is a solid server/client solution for VDR. That is the other and probably biggest reason users have abandoned VDR in favor of myth. Yes there are things like streamdev or xbmc+vdr, etc.. But those options are either too limited or too much hassle. It would be great if we could just set one software (VDR) up and keep things lean. I don't think this is something we'll see any time soon, if at all. But then a lot of people said the same thing about support for hdtv and an awesome osd. :) Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
On Wed, Aug 19, 2009 at 1:18 AM, Torgeir Veimotorg...@pobox.com wrote: Ideally you would like to have the 9400/9500 type GPU that can do both h264 and VC1. Initially you might think you do, since you'd like to playback bluray material in the future. But in fact, most of the time you'd be displaying h.264 from HDTV transmissions, and deinterlacing it, if it's 1080i. Not all the different GPUs can do the advanced (temporal) deinterlacing for 1080i material. In most cases, a 9500gt is the better choice, since it can do just that, even though it doesn't support VC-1 decoding in hardware, while a 8400gs can do that, but not deinterlace it. For a more thorough answer, have a look at the mythtv mailing lists. That's all and well but you should be slapped for that last sentence. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD output - your current favourites
On Thu, Aug 13, 2009 at 2:35 PM, Gavin Hamillg...@acentral.co.uk wrote: My current vdr-1.4.7 (compiled 2 years ago as of tomorrow!) is still serving me well.. I have a Technotrend FF DVB-C doing all the heavy lifting, but as time moves on and HD content becomes more prevalent, I'm thinking of moving up. Right now I have an EPIA 800MHz quiet PC with the Technotrend giving me lovely SCART RGB out... if I got a nice LCD TV, what setup would be ideal for driving the HDMI input? Most of the content is still SD, and I am a real pedant about smooth video / interlaced output for scrolling text / live sports. Any time that I've played with vdr-xine or xineliboutput over my years with VDR, it's always been a bit juddery due to VGA timing not matching up with the TV.. is that improved any in the world of HD / HDMI? I have a few VDR boxes and all of them now are using Nvidia cards and vdpau. I output the audio/video to my nice fancy tv with DVI-HDMI cables. It works great. I'm not sure what you're really asking though when you say what setup is ideal. That completely depends on _your_ needs wants but the only people I know with 'juddery' playback only experience it because the video card they have doesn't really have enough horsepower for the higher end hd content. Which could be solved by simply buying a different inexpensive video card. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD output - your current favourites
On Fri, Aug 14, 2009 at 9:18 AM, Andrey Kuzminmailli...@egodot.net wrote: And what DVB cards that support HD and are supported by current kernel drivers are in favorites now? I don't keep a list of dvb cards drivers but you should know that dvb cards don't care if you're watching sdtv, hdtv, or whatever else. They don't care if the stream is mpeg2, mpeg4, etc. The only thing that is important is whether or not your dvb card supports the method the stream is broadcast (ie: modulation, fec, etc). The only exception is if you want to use a full featured, or in others words a card with an onboard mpeg decoder. In that case the onboard decoder needs to support whatever encoding is used in the stream (ie: mpeg2, mpeg4). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD output - your current favourites
On Fri, Aug 14, 2009 at 1:03 PM, Andrey Kuzminmailli...@egodot.net wrote: So old WinTV Nexus DVB-S is enough for those experiments? As long as it supports the modulation fec of your provider, yup. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which Kernel / DVB Driver for VDR1.7.8
VDR-1.7.8 uses dvb api 5 which has been included in the kernel since 2.6.28, so no you don't need a separate source. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.8 xine-9.2 compile error
VDR-1.7.8 needs xine-0.9.3. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Truecolor osd and speed.
Some questions have come up about how to have a high resolution/color osd without having to sacrifice the speed of the osd. VDPAU users have noticed that when using a high resolution theme in yaepghd, it can take 5+ seconds for the osd itself to even be displayed. Per Klaus, VDR's position is this: VDR renders its OSD into an array (of 8 bit indexes into a palette right now, and of full 24(rgb)+8(alpha) bit color values for truecolor) and its up to the device implementation how it transfers that array (or parts of it) to the actual display hard- or software. Some suggestions by Rnissl have been: -Similar way the eHD handles it -Allow osd areas to overlap and put such images into separate areas -Extend the osd api for scroll commands I thought this was important enough of an issue to post to the mailing list. Hopefully those with knowledge on the subject will participate and a good method can be established. We're finally getting the truecolor osd, just have to make sure it's usable and doesn't suffer from massive slowdown! :) Please, discuss! Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine settings for VDPAU SD and HD
I don't know if this will help you any but I use xine-vdpau for both sdtv hdtv. I haven't changed anything in .xine/config so the buffer settings and so on are whatever they are as default. My box runs debian with vdr-1.7.7 and xine-0.9.2 in case that matters. Currently using xine-vdpau r266 released earlier today and nvidia driver 185.18.14 with an 8400GS (with spdif connected to it). I don't think it matters but I'm outputting to a tv using dvi-hdmi cable. I start xine with: xine -A alsa -V vdpau --post vdr_video --post vdr_audio vdr://tmp/vdr-xine/stream#demux:mpeg_pes --verbose=2 --fullscreen --no-gui --no-mouse --deinterlace --no-logo --no-splash ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] making VDR ext4-ready
On Sun, Jun 7, 2009 at 12:01 AM, Thomas Schäfertschae...@t-online.de wrote: Am Sonntag 07 Juni 2009 schrieb VDR User: Why not use the XFS filesystem? Proven high performance with large files, perfect for an htpc. He asked for ext4, not for suggestions for filesystems. If you look closely you'll notice a question mark in what I said. I would hope I don't have to explain any further. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] making VDR ext4-ready
Why not use the XFS filesystem? Proven high performance with large files, perfect for an htpc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Fri, Jun 5, 2009 at 12:35 AM, Nicolas Huillardnico...@huillard.net wrote: Could you please both detail a bit the DVB sources, software versions, plugins, patches, etc. related to HD, that you actually use now ? (DVB-T, DVB-S or S2, DVB kernel patches, VDR core, xineliboutput or xine plugin, xinelib patches...) I use DVB-S sources on VDR-1.7.7 with just basic plugins and xine-vdpau (r260). No special patches are needed for/to anything although I do use vdr-1.7.3-ntsc-fps.diff which changes the default framespersecond to 30.0 (NTSC) instead of 25.0 (PAL), although I've heard this is not necessary now that VDR uses mpeg-ts. It's really straight forward. Maybe there is an english howto somewhere ? There are english forums at: http://dvbn.happysat.org (they have a linux specific forum there which is very active) http://www.hoochvdr.info (good howtos but not actively kept up anymore _I think_) vdrportal looks like a good forum but as already pointed out, it's in German and thus practically useless for all of us english-speaking users. On a side note I just want to say that I see some posts here about peoples expectations.. I want to record X, and Y, while playing Z with no dropped frames, etc etc. I hope you guys understand that things like that are not only related to software. Your hardware is a factor and if your hardware can't do it then it can't do it and doesn't automatically mean there's a problem with your software. Your signal matters too. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
VDR + hdtv has been pretty stable for me for some time now. The few problems I ran into (with VDPAU) were quickly fixed by the xine-vdpau devs. I'm not the only one either, I know a bunch of guys doing the same. It's a highly discussed topic and I'm honestly surprised to hear someone suggest it's in an unstable/crashing/unusable state. My experience has been basically the opposite of that. I would recommend you make sure to have a nice good signal, proper configurations, etc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] error compiling vdr 1.7.7 (frontend.h - '__u8' does not name a type)
Or you may also just do this: --- vdr.c.orig2009-04-12 11:05:51.0 -0700 +++ vdr.c 2009-04-12 11:07:08.0 -0700 @@ -32,6 +32,7 @@ #include pwd.h #include signal.h #include stdlib.h +#include linux/types.h #include sys/capability.h #include sys/prctl.h #include termios.h ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
On Thu, May 28, 2009 at 5:09 AM, Falk Spitzberg p...@spitzberg.de wrote: Hello, i recently built a vdr-1.7.6 + reelbox pluging, following the vdr-wiki for VDR DVB-S2 on OpenSuse. Everything was build properly, but unfortunately the eHD freezes after a few Minutes (not only when replaying recordings, but also with live TV). I know that there are some problems concerning the new TS format of VDR. Does anyone have a solution for this problem? I don't like the idea to use VDR 1.7.0 or an even older version. Sounds like a problem with eHD. I've been using 1.7.x with mpeg-ts and have never seen the problems you describe. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
On Thu, May 28, 2009 at 7:50 AM, Josce jo...@welho.com wrote: Reelbox plugin still occasionally freezes, but so it has always done. The reelbox plugin is of course a joke and I deeply regret buying the card from Reel-Multimedia. Hopefully the VDPAU is more promising. Sorry for OT but just wanted to note that I and many other users I know are using VDPAU now and it works great. I believe the devs are preparing to submit a patch to Darren Salt so it may become a part of vanilla xine-lib. A huge thanks to the devs for their work! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ExtensionHD and VDR 1.7.6
On Thu, May 28, 2009 at 8:16 AM, Luca Olivetti l...@ventoso.org wrote: En/na VDR User ha escrit: On Thu, May 28, 2009 at 7:50 AM, Josce jo...@welho.com wrote: Reelbox plugin still occasionally freezes, but so it has always done. The reelbox plugin is of course a joke and I deeply regret buying the card from Reel-Multimedia. Hopefully the VDPAU is more promising. Sorry for OT but just wanted to note that I and many other users I know are using VDPAU now and it works great. I believe the devs are preparing to submit a patch to Darren Salt so it may become a part of vanilla xine-lib. A huge thanks to the devs for their work! OTOH with my setup it works poorly (artifacts, banding, freezing, changes in color, etc.) and I'm not the only one, so I'm not sure vdpau support is mature enough for inclusion in xine-lib. Are you sure you're not experiencing driver problems? Btw, the vdpau devs are really good about fixing things if you provide them with a sample to work with. A backtrace doesn't hurt either. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] What is the best linux distribution for VDR?
My preference, and many guys I know are using Debian. Also a few Gentoo guys in there. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Sat, May 16, 2009 at 8:57 AM, Patrick Rother krd-...@gulu.net wrote: As most pause key pressings are accidental, this is quite annoying. That is user-error, not a problem with VDR. I'd prefer to have a switch to disable recording at all. Although you can easily resolve your problem by simply paying attention to what you're doing, I don't see a reason why Klaus wouldn't be willing to add something to help those of you who can't get it under control on your own. That's just my opinion though, nothing more. Maybe VDR should come with a helmet too! ;) Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] NVidia ION mini-ITX arriving
Thanks for the feedback on this hardware! There are many interested parties (myself included) so it's great to hear some real world experiences. Have you tried throwing any VC-1 at it yet? Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Mplayer and mp4 files
On Fri, May 15, 2009 at 9:19 AM, Diego Pierotto vdr_ml...@tiscali.it wrote: i really don't know where to put it inside mplayer.sh script. Look at the end of the mplayer.sh script and you'll see where $CMDLINE is used on the mplayer execution line. Just add it there. For example (this is not from mplayer.sh but the same concept): sudo DISPLAY=:0.0 $CMDLINE $1 /logs/mplayer.log would become: sudo DISPLAY=:0.0 $CMDLINE -demuxer mov $1 /logs/mplayer.log ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR shutdown problem(?)
What's the best way to shut down VDR without the process exiting prematurely? By that I mean before it has performed all of it's cleanup tasks (like saving setup.conf, channels.conf, etc). I was told that the method that comes with runvdr (/usr/bin/killall -q -TERM) kills it instantly and it doesn't have time to do cleanup. Also, can an svdrp command be added to perform a VDR shutdown? I notice the svdrp command QUIT described as Exit VDR but after testing this command, nothing happened. Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reccmds.conf
You probably don't want to force aspect ratio unless you don't care about possibly breaking it. Also, forcing a maxbitrate and then using quantizer is totally pointless. Stick with just a max quantizer only, no minimum and no bitrate limits. Better yet, since that command line is horrible I'd suggest you just search for a script that can generate a good command line for you. When it comes to encoding audio/video, one size certainly does not fit allbut that's a conversation for a different thread. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] NVidia ION mini-ITX arriving
I'm excited to try the Nvidia Ion platform for an htpc. However, I'm going to wait til the price comes down some. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] yaepghd-plugin
On Tue, May 12, 2009 at 9:20 AM, Jouni Karvo jouni.ka...@iki.fi wrote: Ah, actually, all I needed to do was to edit one setting in the vdr-xine Makefile. Working finely now! Ahh sorry, I was thinking of when using vdpau. :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Editing usability
On Mon, May 11, 2009 at 1:36 AM, Stuart Morris stuart_mor...@talk21.com wrote: I haved lost count the number of times I have pressed the numbered keys on my remote by accident and then panic because I don't know how to undo what then happened. This is definitely a trap for unsuspecting beginners. I mean this in the nicest way possible but paying more attention to what you're pressing would pretty much resolve your problem. In all honesty most of the complaints I've read have little or no real issue with VDR itself but rather the users either not paying attention to what they're doing, not bothering to read the manual memorize the few keys involved, and/or wanting VDR to kid-proof the remote for them. It seems all of these problems could be eliminated with a little extra effort by the user. That being said, if there's something that could be done to help and Klaus is willing to do it then super. Or better yet if someone else takes it upon himself to create these patches so Klaus can be left to focus on the bigger fish to fry. For the record, I have kids, who can be more like monkeys often times, and have no problem keeping the remote away from their curious fingers. I've accidentally pressed buttons that had undesired actions before as well. So, when I say these problems can be resolved with a little more effort attention on the users part, I'm speaking from experience. Of course it's easier to decide you can't be bothered with it on your end and ask someone else to fix it for you, but truthfully speaking the user-side fix isn't exactly hard to begin with. I guess we'll have to agree to disagree as to how serious of an issue this stuff is, or whether it's even a problem with VDR itself or not. Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
If you don't want VDR to record when pause is pressed, how do you expect to resume play from the point at which you pressed pause? Obviously it has to record the stream somewhere since there is no live tv caching in VDR. Next, you _do_ have the option to delete these pause/instant recordings, you just go into the recording menu and do it. VDR doesn't just assume you'd like to discard it, as it shouldn't. This is one of those things where people will complain either way. Users who want pause-recordings deleted automatically complain that they're not. Users who want to manage this themselves will complain if they are. Maybe there's some middle ground where the user can choose which behavior he prefers, and takes minimal effort to implement. After talking to some users about this subject, it seems most would actually prefer live tv caching as an option. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Sun, May 10, 2009 at 1:49 AM, Andrey Kuzmin mailli...@egodot.net wrote: If there's any intention to add live tv caching then ram should definitely be available to the user as a storage option. Although I don't really care about the feature, I don't mind if my ram is being used whereas I absolutely don't want a harddrive constantly running for it. Btw, I haven't paid more then $20 for 2x2GB sticks of ram in ages, though I always take advantage of MIR's on them. I actually have 8GB sitting new in the packaging but didn't want to pass up some great deals. :) RAM + HDD = SSD More like flash ram + hdd = ssd. You don't want to use an ssd for something like this just yet. Btw, I picked up a 30GB ssd drive which is now the os drive on my Vista 64 desktop. Damn nice! Boots to desktop in about 7 seconds. Almost no load time for apps (even large with many plugins). I can't wait until ssd technology matures a little more and the price drops! Overheating, spinning... it's something from dinosaurs' era :)) Yes! :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Sat, May 9, 2009 at 3:30 AM, Gerald Dachs v...@dachsweb.de wrote: Am Sat, 09 May 2009 10:33:58 +0300 schrieb Jouni Karvo jouni.ka...@iki.fi: No, I meant deleting automatically the pause-live-TV recording. That recording is conceptually just a technical implementation issue (and should not be visible in the recordings list, even, in my opinion). The end user needs not care for the object structure of VDR source code, and the implementation of pause-live-TV is in the same category. This is the first good idea in this thread. In my opinion the first good idea was when someone said to keep your kids away from the remote. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Sat, May 9, 2009 at 4:05 AM, Gerald Dachs v...@dachsweb.de wrote: Am Sat, 09 May 2009 12:38:39 +0200 schrieb Klaus Schmidinger klaus.schmidin...@cadsoft.de: It also raises several questions: - When should such a recording be deleted? If it gets deleted as soon as replay is stopped, you'll be very surprised when you (or your kids ;-) inadvertently press Stop, and you can't resume replay. Shit happens, not really a problem. Kids pressing remote buttons is one of the main reasons this thread was started so apparently for some people it really _is_ a problem. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Sat, May 9, 2009 at 1:04 PM, Udo Richter udo_rich...@gmx.de wrote: On 08.05.2009 01:17, Andrew Herron wrote: I agree it must put extra wear stress on the hard drive and yes the energy usage must be higher. I don't think so. Disks don't wear that much by reading and writing. Spinning up and down, heating up and cooling down, shaking them, do lots of seek operations, thats wearing a hard disk much more. (Flash disks are different.) Heat (ironically in some cases helps performance) especially wears parts faster. Putting a fan on a harddrive only keeps the housing cool, which is a good thing, but it doesn't do anything for where the heat is actually being generated. You can run a harddrive 24/7/365 but when you do that there's a higher risk the next time you spin it up you'll hear clicking. OTOH, 4GB of RAM isn't very expensive any more, and should be enough for roughly 1h of HDTV with good quality (~9mbit), or? If there's any intention to add live tv caching then ram should definitely be available to the user as a storage option. Although I don't really care about the feature, I don't mind if my ram is being used whereas I absolutely don't want a harddrive constantly running for it. Btw, I haven't paid more then $20 for 2x2GB sticks of ram in ages, though I always take advantage of MIR's on them. I actually have 8GB sitting new in the packaging but didn't want to pass up some great deals. :) Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Editing usability
On Sat, May 9, 2009 at 1:04 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: Personally I don't find the key mapping that unintuitive. After all, the number keys are unused in replay mode, so why not use them for editing? 2=Cut 4=Move Back 6=Move Forward 7=Jump Back 8=Test 9=Jump Forward 0=Toggle That should be perfectly fine as probably every remote had number keys and they're certainly all going to be grouped together. In my opinion those are the _only_ keys that make sense for editing. If it's really a problem for people to remember those 6 functions, you could always just display them on the osd with the press of the info button or whatever. The only key you really should make an effort to remember is 2 (cut). I've forgotten the others before but with a couple seconds of fiddling around with the other numbers, I quickly rediscovered what each did so it's never been any real issue here. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Fri, May 8, 2009 at 10:30 AM, Pasi Juppo p...@juppo.fi wrote: VDR is very nice. I've been using it for years now. But it is still very much tech focused in many areas. E.g. cutting recordings is way too complicated for non-tech persons. Could you elaborate on this? The editing in VDR is very simplistic and requires no real technical skill at all. It's nothing more then setting cut points, frame stepping, and performing the cut. The user only has to know what he wants to cut/keep so I'm not sure why anyone would say it's way too complicated. I know there are some people who mix with computers like water oil but if you can manage to use the remote, you should be able to edit just fine. ;) Regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Thu, May 7, 2009 at 11:38 AM, Jouni Karvo jouni.ka...@iki.fi wrote: I'd be pleased, if there would be some kind of a caretaking, so that the pause-live-tv recording would just disappear after returning to other modes of operation. I think it would not break anything for the user, since you can always use the specific recording button in the menu to create an actual recording. If you want to pause live tv, how else would you suggest caching the stream? It's either going to be to ram or some storage device, and if you don't save the stream (aka record it), how are you supposed to play it back? Unless you mean VDR should somehow determine that you've caught up to live tv from playing back at the point you paused it, and then delete the recording/cache without caring if you wanted to keep it for any reason. I really hope Klaus never intends to implement something like the live tv buffer that myth has. The idea of one of my harddrives saving nonstop 24/7 is really really lame. Huge waste of power, constant heat, and unnecessary wear on the harddrive for something that probably doesn't even get used that much in the first place. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Thu, May 7, 2009 at 5:00 PM, Torgeir Veimo torg...@pobox.com wrote: 2009/5/8 Andrew Herron totallyma...@gmail.com This is a very popular feature in the Sky+ SkyHD PVR's from Sky here in the UK as it enables them to offer the ability to rewind 'Live TV' in an ad-hoc way (at least to the point where you switched over to the currently viewed channel) I agree it must put extra wear stress on the hard drive and yes the energy usage must be higher. There's no need for this stream to reach disk. A 512MB in memory buffer should be sufficient, and ram is cheap these days. 512MB won't get you far with hdtv. It won't even get you 5 minutes worth. Needless to say, you'd need at least a few GB of dedicated ram to even bother with it. At least ram is cheap now as you've pointed out (especially if you take advantage of MIR's). After seeing how much money I was wasting every month in my electric bill just by not setting a sleep timeout on my harddrives, ram is the only place I'd want any caching like that to take place if I were interested in buffering live tv. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2 little bugs report
On Wed, May 6, 2009 at 6:07 AM, Alex Betis alex.be...@gmail.com wrote: Same issue here with my 2 year old kid. But I think he presses the big red glowing button on MCE remote :) Confirmation will be a good idea, but not by pressing the pause button twice. I think it could be a good idea to implement multiple-button commands and allow configuration for every command. By default it could be set to once pressed pause button, others might set it to pause+ok. This will solve some more problems I can think of, such as remotes with few buttons, so sequences will allow them to use much more VDR commands. Maybe there is a need for a single point of remote control processing where that multi-button feature will be implemented, so all other plugins could use it somehow. This sounds like a lot more work then simply getting a remote that better suits your needs. For the record, I also have accidentally started an instant-recording but after years of using VDR, I've only done it a few times and it was no problem to just delete go delete it. I also have intentionally started an instant-recording and am glad I didn't have to confirm it. Call me crazy but problems like 'my kid starts recordings' and 'my remote doesnt have enough buttons' seem like issues easily solved by the user, not VDR. And yes, I'm a parent too. I guess Klaus will decide is addressing those is appropriate for the VDR core but if so, I sure hope the new osd implementation comes first! :] Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Wed, May 6, 2009 at 10:32 AM, Brian brian_dorl...@t-online.de wrote: Isn't pause live TV an instant recording. My VDR has some plugins, no patches, and has IMHO always done that. Yes, pausing live tv was added over 6 years ago in VDR-1.1.28 actually. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Tue, May 5, 2009 at 2:18 AM, marti...@embl.de wrote: Well, keeping the remote control away from my kids is not easy unless I han g it from the ceiling. Is there some way I can disable live tv pausing all together? It is causing a lot of trouble and I don´t reallly need that feature... If you're kids are old enough to talk then they're old enough to understand don't play with the remote. If not, they're too little to reach up very high. Whichever the case, it sounds like your problem can be easily solved without modifying remote.conf, VDR core, or anything else. I couldn't imagine fighting with a kid over something like that. No way! ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.1.4
On Tue, May 5, 2009 at 11:07 AM, Petri Helin phe...@googlemail.com wrote: Antti Ajanki wrote: New version of the Webvideo plugin is available at http://users.tkk.fi/~aajanki/vdr/webvideo/ Hi Antti, since it sounded such a nice plugin I decided to give it a try, but am still trying, because the installation it not what someone might call simple :) First of all, it installs the binaries under /usr/local/bin, but then it uses a hardcoded path of /usr/bin in several places. Secondly, it's incompatible with python 2.6, which I believe is the default version with recent distributions. Thirdly, it brings down the whole VDR if it cannot connect to the daemon. But, as I said, it sounded like a nice plugin so I am still working to get it running. I actually had the homepage for this open in a browser to remind me to try it but based on your results, I'll wait until those problems are fixed. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
I keep seeing mention of people using computer monitors and that VDR should be designed to accommodate their aspect ratios. I'd like to point out that plenty of users don't use VDR with a computer monitor at all. Like many others, I have an hdtv (60 in my case) and would love to have an osd that 1920x1080 always, regardless of the content I'm watching. Why? Because my tv can handle it so why not? My main VDR box is in my living room, tucked away behind my tv with no keyboard, no mouse, no monitor, no anything. I do have a test box connected to a 19 monitor but certainly our primary VDR use is on a real tv so that's where our main concern/interests are. I'm not sure what the best way to deal with this situation is but I strongly urge patience and proper design so nothing is force while looking ok for some people but like crap for others. Not everyone uses computer monitors for their output device, and not everyone uses a tv (of whatever size/aspect ratio). Surely there's a sane reasonable solution that works for *. Maybe some user settings are required so people can tweak the osd to look good with their specific display type? Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
I've only ever used vdr-xine and I must say it's pretty easy to get going. I've never used (or installed) Linux as a desktop either, maybe that's where people get problems? For years it was console-only Debian with nexus-s tv-out. When that didn't cut it anymore due to things like hdtv, hdmi, etc. I bought a cheap vdpau video card, tried vdr-xine for the first time, and have been happy ever since! The few problems I had were all code-related and quickly resolved by the developers so I couldn't be happier. The old advice is still true, use whatever works for you. :) Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
On Tue, Apr 28, 2009 at 12:56 AM, Peter ze...@ruksis.com wrote: I have a bit of a problem running xine frontend – it will not reconnect if vdr backend restarts. Also, my vdr can take 10-15secs just to start up, and xine frontend will bail out during that time, too. Since frontend is being run on unattended TV box (read: no keyboard) it is cumbersome to restart xine every time this happens. In my tv script I do this before starting xine: until [ -e /tmp/vdr-xine/stream ]; do sleep 1; done This waits until vdr-xine has started before loading xine itself and resolves the problem of delayed startups. Second problem: xine does not work with vdr mplayer plugin (mplayer cannot access X, hence no video). Are there any alternatives? I'm using VDR-1.7.6 with xine-0.9.1 and the mplayer plugin just fine. Maybe you're missing the required mplayer.sh(.conf)? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
On Tue, Apr 28, 2009 at 7:23 AM, lucian orasanu o_luc...@yahoo.com wrote: on an gentoo distro and i start xine from .xinitrc like this: /usr/bin/xine -V vdpau -f -pq -A alsa --post vdr_video --post vdr_audio vdr://tmp/vdr-xine/stream#demux:mpeg_pes I start xine only from my tv script. I don't use .initrc for anything, maybe that's something to consider. and for mplayer ihave this on mplayer.sh #!/bin/sh CMDLINE=mplayer -fs -vo vdpau -ao alsa -cache 4096 -slave -nolirc -quiet DISPLAY=:0.0 $CMDLINE $1 |logger exit Mine is: #!/bin/sh CMDLINE=mplayer -fs -vo vdpau -vc ffh264vdpau,ffmpeg12vdpau,ffvc1vdpau,ffwmv3vdpau, -ao alsa -cache 4096 -slave -v -noconfig all -idx #CMDLINE=/pluginsrc/xine/xineplayer -fs -vo vdpau -ao alsa -cache 4096 -slave -nolirc -v sudo DISPLAY=:0.0 $CMDLINE $1 /logs/mplayer.log exit ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
On Tue, Apr 28, 2009 at 1:20 PM, Simon Baxter linu...@nzbaxters.com wrote: I've recently taken a different approach altogether. I use MyMediaSystem (mms) as the front end to my pvr for dvd, movies, pictures, music, weather, radio etc etc and TV. When you select TV, it launches vdr-xine. I wanted a high quality graphical (open-gl) look - and the ability to play music playlists while cycling through my photo collection. VDR, vdr-xine and mms seem to work very well together too Interesting. Do you have a howto for this? I'm sure I know some guys who would like to try it as an alternative to xbmc+VDR. Thanks, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] Skin EnigmaNG v0.1.0
On Sat, Apr 25, 2009 at 9:22 AM, Andreas Mair andr...@vdr-developer.org wrote: Hi VDR User (Derek?), let's talk about that when high color OSD is available in vanilla VDR. At the moment I don't see a reason why not to support it, but time will tell... I'll take that as a maybe! ;) Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
