Re: [vdr] read-only video directory
2013/3/6 Peter Münster pmli...@free.fr: On Wed, Mar 06 2013, Stephan Loescher wrote: The workaround I use is to mount the server in a subdirectory e.g. mount the server-directory to /net/media/data/video/servervideo and start the client-vdr like this: vdr -Pstreamdev-client -Pxineliboutput -v/net/media/data/video On Wed, Mar 06 2013, Udo Richter wrote: You can always mount an unionfs or aufs on top of the read only mount, and redirect all write access to a local disk or ram disk. That way VDR will be able to write its status files without changing the source file system. Hi Stephan and Udo, Unfortunately I don't understand. Could you please show examples? I have for example this directory: /net/media/data/video/Pippi-geht-von-Bord/2010-07-31.06.55.50.99.rec The slave (nfs-client) should read it, but it should not write anything to this directory (or its parents). Is this possible with your solutions? With a union filesystem you can mount the lower level read only and have an upper layer where changes get stored. So yes - the master file system will for sure not be touched and you can keep VDR as is and keep full functionality. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] emergency restart is too fast for my USB DVB-T receiver
On 28/10/2012 20:50, cedric.dew...@telfort.nl wrote: Hi All, I have an usb dvb-t receiver. When something goes wrong, (for instance when I unplug, and then re-plug the receiver) I see in my syslog something along the lines of video data stream broken or error stopping stream. Then vdr restarts itself. The problem is that the kernel does not reinitialize the receiver until nobody is using the device. reinitialize takes a few seconds, but vdr does not release the device long enough for that to happen. The result is that vdr restarts many times. When I stop vdr, wait a few seconds, and then start it again, the USB receivers work fine again. Is there a way to let vdr wait for 10 seconds during the emergency restart? In your restart script (typically runvdr, depending on your linux distribution, you need to put a sleep at the right place. No need for anything complex. The good solution would be to get the driver for your device fixed. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Force VDR to save channels.conf
On Sat, 26 May 2012 20:56:43 +0200 Artem Makhutov ar...@makhutov.org wrote: I think that last time I had to do this I had to connect via VNC and the vdr-ffnetdev plugin to get the OSD and to press the power button to make it shutdown and save the changes... Is there an easier was to do this? svdrpsend hitk power - also works over the network - if configured for that. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] what happened with vdr-portal's irc-Server???
On Sun, 22 Apr 2012 19:43:39 +0200 Halim Sahin halim.sa...@t-online.de wrote: Hi, It seems vdr-portal's irc is down or I did something wrong! Or maybe the adress has changed? BR. halim The server of vdr-portal has been upgraded - irc is not yet fixed and will be fixed when the person in charge finds time for it :) So no you are doing nothing wrong. I think at the moment most people are using irc.freenode.net #vdr-portal ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Sun, 08 Apr 2012 11:54:21 +0200 Manuel Reimer manuel.rei...@gmx.de wrote: Klaus Schmidinger wrote: This method may have been useful in the old days where large harddisks were unavailable or hard to come by. Now we're living in the age of terabyte disks, and setting up a VDR with 1TB of video storage (even using a second disk to have a RAID-1 for data safety) os no big deal any more. Especially with HDTV the amount of disc space, used for recordings, also got bigger. Isn't LVM the keyword here? No. It is virtually impossible to just merge in a second disc if the first already has data on it and hasn't been set up as LVM physical volume on first install. You would have to move all data to another disc to set up the first VDR disc from scratch with LVM. After setting up, all data has to be copied back. I think it requires several hours to set that up. With the VDR multiple disc feature, I just install the new disc and mount it -- Setup done. Another big disadvantage of LVM is, that it is nearly impossible to restore data of one of the LVM discs, if only one disc is available. Means: If one disc dies, all recordings are gone. Try mhddfs - the only thing it misses from vdr behaviour (if partition size is chosen well) is to put the small files on another harddisk, then the bigger files (i.e. put index and info on 00 and all the rest somewhere else). Knowing the history of bugs on that part (also, but not only in vdr core) its a wise choice to drop support for it (i say that even if i'm a user of that feature and like it a lot !) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Sat, 07 Apr 2012 19:24:17 +0300 Anssi Hannula anssi.hann...@iki.fi wrote: FHS patch This change would be welcome (I'm the VDR package maintainer of Mageia distribution), though it hasn't really been a big issue for me. A couple of comments regarding the INSTALL part: 06.04.2012 16:01, Christopher Reimer kirjoitti: +CACHEDIR = /var/cache/vdr +CONFDIR = /var/lib/vdr Just for the record, this is a bit against FHS rules (Users must never need to modify files in /var/lib to configure a package's operation.), but there really is not better option either... (maybe fhs-discuss@ could be asked for a clarification). vdr has 2 types of conf files - 1) internal databases - like channels.conf, setup.conf 2) real conf files like scr.conf, diseqc.conf etc 1 should be in /var/lib/vdr 2 should be in /etc/vdr/ This is kind of hard to handle properly as vdr doesn't make this distinction. conf files in /var/lib is a no-go, application changed files in /etc is a no-go either. +LOCDIR = $(PREFIX)/share/locale +PLUGINLIBDIR = $(PREFIX)/lib/vdr +RESDIR = $(PREFIX)/share/vdr +VIDEODIR = /srv/vdr/video0 Ditto here, /srv contains site-specific data which is served by this system., which video data really isn't. (btw, why 'video0' and not 'video' like is VDR default?) If video is served by vdr or not is a bit of opinion. IMHO recordings is THE data served by vdr, it should not be hidden somewhere in /var/lib , in yavdr we also make it available in the local network by smb and nfs - those we use this directory. video0 , because it allows for easy extension of storage space, without reconfiguring vdr, video1, video2 and videoX will be used autmatically by vdr at next start. On Mandriva/Mageia packages I use '/var/lib/vdr/config' and '/var/lib/vdr/video', but as I said, they aren't really any better than your suggestions :) Maybe just add a note that the INSTALL example doesn't really conform to current FHS? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.26
On Sat, 10 Mar 2012 21:26:36 +0200 Mika Laitio lam...@pilppa.org wrote: Damn, too late for today... :-) Just finished the noepg-plugin-skeleton at So according to README this plug-in replaces the noepg.patch. What is the functionality/purpose of this noepg patch/plugin? The patch exists a couple of years already i think. It's to block DVB EPG Events from EIT for defined/chosen channels. If you use external EPG, you might not want the internal EPG to interfere with it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Local frontend - using XBMC strm vs vdr-sxfe
On Fri, 9 Mar 2012 09:59:51 + Dominic Evans oldma...@gmail.com wrote: Hi all, Running vdr-sxfe as a local frontend using a pipe _should_ be as fast (if not faster) than using XBMC over an http://localhost streamdev connection. However, I seem to find the opposite to be the case. vdr-sxfe still struggles with HD content, has pops and clicks in the audio, crashes out every now again and generally has inferior playback. My experience is that xine frontend runs usually more stable, then vdr-sxfe. If you run sxfe without HUD enabled, video is pretty ok, but gets jerky if you have OSD open. With hood enabled you get this skippy behaviour described in some other answer. On my main frontend I have VDR running full time in the background with no local frontend running. Then I have a bare-bones X11 configured with a simple .xinitrc that flips between running vdr-sxfe and xbmc (as I prefer it for watching DVDs etc.). For both frontends I am using VDPAU. I have to use vdr-sxfe to interact with the menus, auto skip adverts in recordings, do cutting, etc. But I'm increasingly finding myself using XBMC and just a directory full of .strm files that point at streamdev TS links, when I want to watch a live HD broadcast. Interesting solution. Does anyone have vdr-sxfe running flawlessly as a local frontend for HD content? I used to use xine as local frontend as its more stable. I just wish I could have the full VDR OSD, but within XBMC :) Most likely will never happen. To answer some points raised in other answers: - default deinterlacing with yavdr is temporal_spatial for SD content and bob for HD content - testing HD deinterlacing settings with 720p stations is pointless as p means progressive aka not interlaced - you can set the deinterlacing settings in the webfrontend (for all frontends, not 100% sure about XBMC) - the xbmc version of yavdr 0.4 isn't optimal anymore, we just did not get around to provide some updated version, current eden with pvr runs a lot more stable, but has other issues (which we did not came around yet to trace them) - there is a new kid on the block called softhddevice, which is local frontend only and based directly on ffmpeg/libav with no libxine involved. Its only a littlebit older then 2 months, those maybe not ready for primetime - but in my opinion providing a better experience then the old xine frontends already. For that oneiric or precise as base is recommended - but this is nothing we can rollout yet. local frontend only is not that much of a backdraw, if you take into account that you can use streamdev with vtp streaming and a local vdr on the client Hope that provides some insight. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xmltv2vdr.pl
On Fri, 9 Mar 2012 15:54:29 + Dominic Evans oldma...@gmail.com wrote: I don't know if anyone else still uses the xmltv2vdr.pl perl script for piping XMLTV data into VDR's epg, but I've been keeping a version of it updated with some additional function here: I don't want to discourage you from that - but have you seen there is a xmltv2vdr plugin ? This might be the better solution on the long run. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, 29 Feb 2012 05:38:06 +0100 Gero geronimo...@gmx.de wrote: On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote: 28.02.2012 12:24, Gero kirjoitti: On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: I'll keep this in mind for after version 2.0. Why so far? Because 1.6.0 was released a long time ago, and we want a new stable version soon? :) Sure! - But next stable version would be 1.8 - wouldn't it? Next stable will be 2.0 AFAIK ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
On 07/02/2012 11:21, Torgeir Veimo wrote: Does anyone have any experience with this plugin, and can offer some opinion on how it differs from the xineliboutput and xine plugin? - no use of libxine - decoding in the plugin (no client executable (yet?), no client/server, less buffers) - decoding with ffmpeg (vaapi/vdpau/..) - very young project still, first impressions of people: some things already working well, of course not ready for production yet Just following the discussion @vdr-portal.de , no own experience yet ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Using second tuner on TT S2-6400
On Wed, 08 Feb 2012 12:22:40 +1300 Richard Scobie r.sco...@clear.net.nz wrote: I have just managed to get an S2-6400 based vdr sytem up and running and am trying to work out how I can use the second tuner. Currently I have a diseqc switch with two dishes connected to tuner 1, which works now I use the -D 0 vdr option. I did think that adding 0: to the top of diseqc.conf file would force it to use the first tuner, but this does not work. In any case, if I add another dish to tuner 2, how do I inform vdr what sources are available on it? I get the impression that a plugin may be required, but I can't see anything suitable on the Wiki plugin page. Any help would be appreciated. Usually you connect the same source to the second tuner (using multiswitch) or in case nothing like that exist you could use channelbonding, using both tuner at the same cable with some additional hardware for a few dollar. Having different sattelites on different tuners is a bit unusual, but possibly you could configure that by using the ca value in the channels.conf - or checking the dynamite plugin which resently got added something like that. I believe there has been recently posted some basic plugin which could be adapted to what you want as well. (would need to search for it) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23
On Wed, 18 Jan 2012 09:58:16 +1100 Hawes, Mark mark.ha...@au.fujitsu.com wrote: Hi, I have tried using my hybrid HVR 4000 card ( DVB-S2 and DVB-T frontends on one adapter ) against 1.7.23 and a new set of V4L-DVB drivers built on Monday. DVB-S channels work fine. However, any attempt to select a DVB-T channel results in channel not available. The Syslog trace during VDR initialisation follows: It looks like VDR is not picking up the second frontend on the hybrid card as a result of the 'Device or resource busy' result which is due to frontend 0 being open on it. If you are using new dvb driver you should only have 1 frontend which has all of the delivery systems. The DVBv3 message also looks suspicious. Can you double check that new drivers are loaded and you have indeed only 1 frontend for that card ? (Not saying that there is not a bug) Regards, -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: Monday, 16 January 2012 2:11 AM To: vdr@linuxtv.org Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.23 VDR developer version 1.7.23 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.23.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.22-1.7.23.diff MD5 checksums: de136f7be28c4b6f1fa0e2218b4acc11 vdr-1.7.23.tar.bz2 2977b75cd8dacad187d11c10b867d56a vdr-1.7.22-1.7.23.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.7.22: - Removed the '.pl' suffix from svdrpsend.pl (sorry, I missed that one). - Fixed bonding more than two devices. - Fixed handling symbolic links in cRecordings::ScanVideoDir() (reported by Sundararaj Reel). - Fixed a memory leak in cRecordings::ScanVideoDir() in case there are too many link levels (reported by Sundararaj Reel). - Removed redundant memset() in the ctor of cSatCableNumbers (triggered by Ville Skyttä pointing out that the argument sequence in the call was wrong). - Removed a redundant NULL check in cDvbSpuDecoder::setTime() (thanks to Ville Skyttä). - Added HasSnr to the DEBUG_SIGNALQUALITY output in cDvbTuner::GetSignalQuality() (triggered by Ville Skyttä pointing out that the variable HasSnr was unused). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Added support for HbbTV to libsi (thanks to Christoph Haubrich). - Added support for devices with more than one delivery system per frontend. This requires a DVB driver with version 5.5 or higher that can handle the DTV_ENUM_DELSYS call. With older drivers it will fall back to one delivery system per frontend. - Updated the Hungarian language texts (thanks to István Füley). - cDvbTuner::ExecuteDiseqc() now makes sure only one tuner sends SCR commands at any given time (reported by Frank Neumann). - cEvent::FixEpgBugs() now replaces any newline characters in stream component descriptions with blanks (thanks to Torsten Lang for reporting a problem with EPG data from BSkyB's MTV MUSIC, S28.2E-2-2010-7012). - Fixed cDvbSubtitleConverter::SetOsdData() (thanks to Rolf Ahrenberg). - Fixed cListBase::Move() in case From and To are equal (reported by Sundararaj Reel). - Added support for DVB-T2 to libsi (thanks to Rolf Ahrenberg). - Added support for handling DVB-T2 transponders. This requires a DVB driver with version 5.3 or higher that can handle the DTV_DVBT2_PLP_ID call (thanks to Rolf Ahrenberg). - Fixed cConfig::Load() for g++ version 4.7.0 (thanks to Ville Skyttä). - Fixed a possible memory corruption in cTsToPes::GetPes() in case of broken TS packets, e.g. when switching channels. - Fixed the SVDRP command CLRE for a single channel in case there are events that have a timer (thanks to Timo Eskola). - BIDI support now checks at runtime whether the system runs with UTF-8 (suggested by Torsten Lang). - Added member functions Adapter() and Frontend() to cDvbDevice (suggested by Rolf Ahrenberg). - The parameters that are only used by second generation delivery systems (DVB-S2 and DVB-T2) are no longer written into channels.conf for first generation delivery systems (DVB-S and DVB-T). - Changed IndexToHMSF() so that it can handle negative Index values. - Added option -N to the msgmerge call in the Makefile, because fuzzy translation mostly resulted in useless strings. - The new setup option Replay/Show remaining time can be used to switch between showing the total length or the remaining time of the recording that is currently replayed. - Fixed wrongfully displaying the length of a recording in the title of the replay progress display. - Fixed frozen live view with device bonding in case the bonded master is used for live viewing (reported by Uwe Scheffler). Have
Re: [vdr] VDR and Hybrid DVB Cards ( was HVR 4000 drivers broken - adapter0/frontend1 busy in linux-media list )
On Sat, 19 Nov 2011 00:40:30 +0200 Mika Laitio lam...@pilppa.org wrote: I've received an email from Manu Abraham, informing me that he intends to change the driver in such a way that there will always be only *one* frontend, even if it can handle multiple delivery systems. So every frontend an adapter will provide will always be useable independent of all other frontends of that adapter. Personally, I like this method more than having separate frontends for each delivery system, and having to manage access between them. Just wanted to let you know that the official implementation in VDR (most likely after version 2.0) will go a different way than your patch. I am wondering what's the reason of breaking this current rule as it sounded so clear...So if cards all delivery systems are mapped as an adapters under same frontend, there must be a some method for querying which of those adapters are tied together. Did Manu say whether that info can be get via dev tree, via sysfs or by using some new ioctl? If Manu is successful in what he is trying (and existing driver following other rules will be ported) then that sounds fine to me. I dont care what solution , but i care for having one. And if the patch wont go in, it means that hvr-4000 owners needs to maintain in addition of the vdr-patch, also a patches for all plugins that the patch breaks :-(. On the other hand, if the patch would be accepted to vdr before 2.0, I am sure that all plugi-ns would be adapter to work in couple of weeks to work with the new interfaces. Its not a drama if on the other hand above happens. If above happens than vdr needs only to adapt to shared ca devices (which are implemented as i.e. caio0 ca0 and need some special handling from vdr side. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was HVR 4000 drivers broken - adapter0/frontend1 busy in linux-media list )
2011/11/16 Manu Abraham abraham.m...@gmail.com: On Wed, Nov 16, 2011 at 4:38 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: That is also my understanding of multi frontend devices. If an adapter has several frontends only one of them can be active at any given time. This has nothing to do with any explosives (excuse the pun ;-) and will be implemented in the core VDR code as time permits. Right now I'm cleaning up the lnb sharing (aka device bonding) stuff and will hopefully find more time for VDR development by the end of the year (and thereafter). If I am following you correctly, There is one issue however. If an adapter can have only a single frontend, then there will exist another issue: - Card has dual multi standard frontend(s). - Card has CI cards on both the paths (2 CI controllers) - Card provides scrambled stream as well as descrambled stream (4 simultaneous streams) - Card needs to swap between the CI modules to take advantage of the different modules, rather than reconnecting antenna inputs/manually swapping the CI modules. Eventually, to handle such a situation: all the nodes exposed to the application has to be under the same adapter, rather than as 4 different adapters, of which 2 of them won't have any frontend or ca devices. To my understanding the mentioned use case would have - according to linux-media project logic of how to handle this - would look like /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/demux0 ... /dev/dvb/adapter0/ca0 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter1/frontend1 /dev/dvb/adapter1/demux0 ... /dev/dvb/adapter1/ca0 so it would be 2 adapter with 4 frontends. If for some reason they should be in one adapter how to distinguish between the different cases ? Maybe i did not understand properly the issue. Anyhow - if such a case exist - it needs to be discussed how it will be handled at driver side and how applications need to talk to the driver - it doesnt help to implement the perfect driver, if nobody can use it. The multi frontend approach for multi-standard devices as described here, should logically anyway only be used if more then one receiption possibility can be connected at the same time. (i.e. if sattelite cable also can contain the DVB-T signal or both can be connected same time) Reading linux-media mailing list doesn't give a clear picture on the rules on one hand , but on the other hand implementations like the mentioned one exist. Preferably the API would describe how to handle it and rules exist for the drivers to be followed, so that applications dont get broken if following the API. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was HVR 4000 drivers broken - adapter0/frontend1 busy in linux-media list )
2011/11/15 Hawes, Mark mark.ha...@au.fujitsu.com: What i got from previous discussions on linux-media is, that if the device nodes are created within one adapter, an application needs to assume that the devices can not be used concurrently and needs to close one device node group before opening the other one. This suggests a constraint in the current design of the way VDR handles the detection and use of DVB devices in that it cannot handle so called 'hybrid' cards where two (or more!) frontends are attached via a single adaptor without restarting VDR and identifying which frontend to use. As already mentioned I wish to use both cards on my system and I'd be interested and happy to help in developing a patch to overcome this constraint. However I would need some VDR architectural guidance to suggest how this might be done with minimal disruption to the current DVB device handling. Any direction would be much appreciated. What i said above is AFAIK more or less undocumented up to now. But it seems to be a consensus between most driver developers now. Yes vdr needs to change to handle this devices properly based on the previous assumptions, i think soneone else can be more helpful than me ;). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Launching vdr + xineliboutput at startup
On Fri, 28 Oct 2011 22:59:09 +0200 Damien Bally bir...@free.fr wrote: Hello 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. For now, I'm doing manually : # xinit /usr/bin/rxvt then type : # vdr -Pxineliboutput I tried to type directly : # xinit /usr/local/bin/vdr -Pxineliboutput but vdr just displays its logo, with no error in /var/log/messages though. I can still launch vdr with : # xinit /usr/bin/rxvt -e /usr/local/bin/vdr -Pxineliboutput but it's not very elegant. What's the trick ? You don't need to start vdr inside X , you start vdr in the background (whatever your init system is). With X you need to start vdr-sxfe . ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr segfault
2011/10/13 VDR User user@gmail.com: On Thu, Oct 13, 2011 at 5:42 AM, Roland Behme r...@nugman.de wrote: What can I do to find out the offending plugin? Try to deactivate the plugins one by one. A core dump and gdb may help as well. Yes and searching the log for PID 25439 (vdr[25439]:...) might give a pointer as well if you find typical log for a plugin with that PID. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: video data stream broken
You might want to check dynamite plugin. If you have different drivers for the different cards you can let it reload that specific driver. If you just want to kick out that tuner until the next reboot (or whatever), thats possible too. 2011/9/19 Dominic Evans oldma...@gmail.com: On 19 September 2011 12:17, Dominic Evans oldma...@gmail.com wrote: I've recently started seeing quite a few instances of a vdr throwing this error (ERROR: video data stream broken) and then initiating an emergency exit. fyi, looking in the logs, this does seem to happen whilst VDR is rapidly switching between transponders presumably during an EPG scan or whilst checking for new channels/transponders. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] XBMC / VNSI discontinued?
On Fri, 2 Sep 2011 23:09:10 +0100 Dominic Evans oldma...@gmail.com wrote: Anyone have more detailed info? It seems pipelka has 'announced' that the VNSI addon is discontinued in favour of his own new XVDR addon. In fact he only did half a comment at github - thats all we know. I forked my own project to get back full control. Thats all i want to say on that topic currently. so it could be just git handling related. Or not - don't know. However, opdenkamp/dushmaniac doesn't look too happy about this situation... http://forum.xbmc.org/showpost.php?p=877324postcount=7 i don't know what happened and what not - i prefer to wait a few days to let things clear up. For me that looks like an over-reaction based on assumptions, which are not valid - on both sides possibly. How does this effect plans for yaVDR 0.4? Is someone already working on deb packaging of this new addon? no effect at 0.4 - whatever works best will be default - current delays are caused more by summer vacations then by anything else. New plugin is already packaged (in unstable/development repos at least). For the add-on i am not sure. Not sure someone tried it yet. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [feature request] recording length computation and storage
Hi ! After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way. Plug-ins which possibly could make use of that are: * live * extrecmenu * restfulapi I'm sure there are more of it. Has someone allready thought of this ? Are there any plans to have that or someone allready using a patch for this ? Thanks ! Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [feature request] recording length computation and storage
On Fri, 19 Aug 2011 12:21:24 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 08/19/11 11:46, Steffen Barszus wrote: Hi ! After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way. How about cIndexFile::GetLength()? This was newly added in version 1.7.20. Not yet - its returning the number of frames - to have one calculation, length in seconds would be required (Ok, its available as well). Also it reads the index directly (if i'm not mistaken, i can barely read C), which would then be read x-times , where x is the number of plugins using it ( + vdr ? I'm not sure of it ). I would think that in recording.h as public member of class cRecordingInfo would make sense. In my understanding the recordings information are held in memory after reading it with ScanVideoDir, this should be part of that information in memory (not reading file from disk for this separately). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [feature request] recording length computation and storage
On Fri, 19 Aug 2011 14:48:46 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 19.08.2011 14:39, Steffen Barszus wrote: On Fri, 19 Aug 2011 12:21:24 +0200 Klaus Schmidingerklaus.schmidin...@tvdr.de wrote: On 08/19/11 11:46, Steffen Barszus wrote: Hi ! After having seen that there are several plug-ins computing the recording length on their own and that being a very expensive task (in respect of io and cpu) and also the same implementation needs to be copied over and over again, i would like to request, that vdr is storing the length of a recording and make it accessible to the plug-ins. I would imagine, that some logic to store it in the info file after/while generating/writing the index would be a good way. How about cIndexFile::GetLength()? This was newly added in version 1.7.20. Not yet - its returning the number of frames - to have one calculation, length in seconds would be required (Ok, its available as well). Also it reads the index directly (if i'm not mistaken, i can barely read C), which would then be read x-times , where x is the number of plugins using it ( + vdr ? I'm not sure of it ). I would think that in recording.h as public member of class cRecordingInfo would make sense. In my understanding the recordings information are held in memory after reading it with ScanVideoDir, this should be part of that information in memory (not reading file from disk for this separately). I don't want to make this part of the 'info' file. Besides, it's only the directory entry that gets read, not the file itself. Where it gets stored is not my point, that it can be served from in meory data read by ScanVideoDir is my point. - readcompute by the core - dont access harddisk for known recordings - dont do it multiple times, if more then one part of vdr wants to know it. If its only in memory and read by the scanner its fine with me. for medium to large recording base we speak about minutes not milliseconds for reading that data. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] will VDR run on this?
2011/8/1 Gerald Dachs v...@dachsweb.de: http://www.geek.com/articles/chips/raspberry-pi-25-pc-goes-into-alpha-production-20110728/ Any thoughts? VDR runs just fine on a seagate dockstar, so I see no reason why it shouldn't run on this device, but I don't believe that it has enough power show the TV signal via hdmi. Not so sure, depending on driver availability: http://www.mikrocontroller.net/topic/224132#2254607 OpenGL ES 2.0 1080p30 H.264 high-profile decode Well lets see, when it apears, if it will be available to normal people AND if the required driver will be there too. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.x + TT S2-6400 + mkv
On Sat, 25 Jun 2011 09:46:20 +0200 Karim karim.af...@laposte.net wrote: Hello, I am looking for a plugin to view hd file (mkv) with vdr-1.7.x and S2-6400. (MPlayer doesn't work here). Any hint please would be greatly appreciated ! As already mentioned. Such a thing does not exist. Your best bet would be to translate the mkv to ts and convert it to a recording. Then it MIGHT be possible to watch. But there is no media player which can output to your device. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
2011/3/30 Oliver Schinagl oli...@schinagl.nl: I belive that is exactly only what this patch does, it changes the positions on the screen for the ST-NG theme I think (it's been a while I admit). So if VDR is told that the red button performs the job of the red button, then everything is ok. To recap, the problem I had with VDR that caused me to write this patch, was: My Remote control had 2 buttons different from where VDR expected the buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote control was Red Yellow Blue Green. So in the end, this patch works for you and does what you want? Or is your remote layed out as VDR expects it? I would say better patch your remote. A sharp knife and a screwdriver might be quite effective and will fix the problem also for the next vdr releases ^^ SCNR Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
2011/3/7 Klaus Schmidinger klaus.schmidin...@tvdr.de: On 03/07/11 14:13, Frank Schmirler wrote: On Mon, 07 Mar 2011 13:33:47 +0100, Klaus Schmidinger wrote On 03/07/11 13:23, Frank Schmirler wrote: Hi, On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-) If you feel like it, you may want to take a look at the code under // Find a device that provides the required transponder: in vdr.c. Maybe you can come up with a better solution... Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs. We only need the EIT data here, which is not encrypted. So it's sufficient to find a device that provides the raw transponder. Ah, I see. I ignored the fact, that at the moment this piece of code is only looking for a way to see the VPS start flag for the timer. Still the GetDevice call (or something alike) would become necessary when considering to interrupt a recording with lower priority. The low priority recording shouldn't be interrupted if the VPS recording cannot start later as e.g. the CAM is in use by a higher priority recording. Looks like this is beginning to become rocket science again ;-) It allready is rocket science right now, ignoring the fact doesn't make it go away ;) At least thats my impression. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] skip +/- 60 sec suggestion.
On Sun, 6 Feb 2011 12:47:33 -0800 VDR User user@gmail.com wrote: On Sun, Feb 6, 2011 at 12:16 PM, Theunis Potgieter theunis.potgie...@gmail.com wrote: IIRC, mythtv had a feature built-in that skips ads automagically. Maybe a plugin could be written for VDR which provides the same function. Would be very cool and resolve the problem with seeking h264 recordings where the still frame will remain unchanged for several seconds and by the time it does change, its seeked several minutes. So with h264 ffw/rew you either seek no where or too far. It's pretty bad unfortunately. There is a package called noad for vdr which makes the marks on where the adverts start/stop. you just need to press skip to jump to the next mark while playing or you can enable it in vdr to automatically jump. This is of course a patch that enables this feature. I'll gladly give it a try but the only url I found for noad just goes to some apache page. Do you have a current url or even hg/git address? there is an actively maintained plugin called markad - which might be worth consideration before ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] distribution of systemd service file
2011/1/19 Paul Menzel paulepan...@users.sourceforge.net: Dear VDR folks, I just noticed that Davide Cavalca added an systemd [1] service file for VDR to OpenBricks [2]. Is it useful to get this included upstream, so that all distributions can use it? I just found this one comment, that these service files supposed to be uniform between distributions [3]. On the other hand I did not find any init scripts in the VDR source. i don't think that such a thing does belong upstream. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new OSD system
On Sun, 16 Jan 2011 06:16:59 +0100 Gero geronimo...@gmx.de wrote: Hello, VDR User wrote: I don't know about any of that but I wonder if the new osd system will be able to maintain widescreen HD resolution even when viewing 4:3 SD channels. Or if it will behave as it currently does, stretches/shrinks according to the channel/recording you're watching. Preferrably it won't do that, or at least be something the user can toggle. My output is always 1920x1080. I opt not to scale SD content up to HD. This means that when I'm watching 4:3 SD content in 1920x1080, I have borders on the left right, which I'm ok with. However, there's no reason I'm aware of why the osd can't still take advantage of the full 1920x1080. That scaling, you're talking about is not related to the new OSD system. Scaling is part of the output device and at least xineliboutput can be configured to not to scale. I was talking about OSD only - independant of the stream-format. In the example I wrote, anthra was configured with 1920x1080 - when I watch TV from FF and hit the menue button, the screen will change to black font on black background :) As far as I understand a statement of Klaus, the OSD will be different depending on the output device. So I wrote about my wish: if the OSD systems already are different, it would be nice to have different configurations too. configure a second vdr instance (on the client or the server) serving the xineliboutput, then you can have 2 configurations right now allready. Its not to much overhead actually :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new OSD system
On Sun, 16 Jan 2011 12:09:34 +0100 Gero geronimo...@gmx.de wrote: Hello, Udo Richter wrote: Its probably a lot easier to solve this at the output side within xineliboutput. So you change a possible issue into a 'NMP'-issue - not very smart. (NMP stands for not my problem) actually i think its wrong setup on your side. call it wrong expectations. see Geralds answer. As allready said, put a streamdev client locally on the server or put vdr on the client and use xineliboutput on the client. You actually want streamdev for client/server. xineliboutput is just an output plugin , not client server. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new OSD system
On Sun, 16 Jan 2011 16:27:47 +0100 Gero geronimo...@gmx.de wrote: With my current setup I do have certain issues. But meanwhile I know how to handle most of them, which means, I don't have any pressure to change my setup. As already said. Start a second vdr instance , using streamdev server and client for the dvb devices, and xineliboutput as output, start the plugins you want for the client on that instance. and you are done. Like that you can also start a second for another client if you are in need. The server vdr/vdr main instance will have all dvb devices, client vdr asking for the channels via streamdev as needed. Thats what gerald was referring to. How you do that is up to you - you did not say anything about your installation, so help on this is impossible. Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
2011/1/14 Laz l...@club-burniston.co.uk: On Monday 10 Jan 2011, Tobias Grimm wrote: 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 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? Tobias has created some time back a command called debianize-vdr-plugin. Using that it should be matter of minutes to create a deb from your plugin (for your local use). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
2011/1/11 Dominic Evans oldma...@gmail.com: On 11 January 2011 01:14, Tony Houghton h...@realh.co.uk wrote: Hm, probably not unless ttxtsubs is useful in the UK. I've been using the Freesat patch up till now, but I'd probably be better off using the Eepg plugin. I can probably borrow Debian bits for that from yaVDR :). Why not exclusively use the yaVDR repositories? https://launchpad.net/~yavdr/+archive/stable-vdr cause its ubuntu and he uses debian ? ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How can I prevent that vdr deletes recordings?
2011/1/4 VDR User user@gmail.com: On Tue, Jan 4, 2011 at 7:21 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: Did the recording only diappear from the list VDR displays in its Recordings menu? Or was it actually removed from the hard disk? I've actually experienced this as well. Recordings vanishing from the recordings list for no apparent reason. If I restart VDR, the list is fully recovered. My dedicated recordings harddrive is located in a lan fileserver, and I had always assumed it was something set wrong in Samba somewhere. Then again when I've looked at the files, all permissions were identical for the recordings that were still listed, and the ones that had magically vanished from the list. I also just realized that when I checked the files, I had ssh'ed into the fileserver from the VDR box itself and could see the files just fine so if it were a Samba problem, that wouldn't be possible. Maybe it really is a bug in VDR somewhere afterall? I think what you are describing is totally unrelated to the problem. Its more likely some timing issue between starting vdr and when the network resource is available. It's kind of sick to share between 2 linux boxes with samba anyway - you might not want that. Check the next time if a touch .update does fix that, and check if the file share was available at the time of last directory scanner run. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] lirc key reading to slow ? Buffer overflow ?
On Wed, 29 Dec 2010 12:14:48 +0100
Klaus Schmidinger klaus.schmidin...@tvdr.de wrote:
On 04.12.2010 12:13, Steffen Barszus wrote:
Hi !
i get these errors, once my remote is doing key repeats:
Dec 3 23:33:13 vdr vdr: [24629] ERROR: unparseable lirc command:
gy_Receiver-event-kbd#012b-Gyration_Gyration_RF_Technology_Receiver-event-kbd#01272
0 KEY_VOLUMEDOWN usb-Gyration_Gyration_RF_TechnoloKEY_VOLUMEDOWN
Dec 3 23:34:14 vdr vdr: last message repeated 583 times
especially note the
usb-Gyration_Gyration_RF_TechnoloKEY_VOLUMEDOWN
and ...kbd#012b- (this should read usb-...)
is there anything forgot to reset ? A buffer to small ?
Just wrong how it is read ? In irw and xbmc there
seems no such issue, means the repeat just works.
i increased the buffers to:
private:
enum { LIRC_KEY_BUF = 500, LIRC_BUFFER_SIZE = 4096 };
which seems to make the error disappear, but its still incredible
slow (compared to other applications) in accept the keys. Can this
be improved ?
You may want to add some debug outputs to cLircRemote::Action() to
see what's going on. From the (garbled ;-) log entry you posted I
guess there is some buffer overflow.
i missed also the sscanf string size - after changing this its better,
the rest is i guess bad interaction with repeat delays (not sure what
#define REPEATDELAY 350 // ms
#define REPEATFREQ 100 // ms
#define REPEATTIMEOUT 500 // ms
do)
isn't lirc suppose to handle repeats instead of vdr ? Anyway after
commenting that part out ( if (count == 0) { in Action) vdr seems a lot
snappier.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Tue, 14 Dec 2010 21:46:52 +0100 Udo Richter udo_rich...@gmx.de wrote: Actually, no one stops you from doing lots of things from within a plugin. The EPG system of VDR has even a multithread safe interface, so you could constantly scan for changes and propagate your own changes. Keeping some SQL database synced two-way should be possible. well the point was to make it simpler, improving something. This goal would be missed by that. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Tue, 14 Dec 2010 10:31:03 +0100 (CET) Gerald Dachs v...@dachsweb.de wrote: Am 13.12.2010 23:21, schrieb Gerald Dachs: Maybe I understand the code in epg.c wrong, but it look like that the whole epg.data file is always read and write complete by the vdr. Even if only one record has to be changed. Maybe the coding with sqlite will look less elegant, but it will be much faster. I/O is always expensive. Afaik the epg.data will be read at startup and written at shutdown. In the meantime the epg data will be read from memory and thats surely much faster than via sqlite. This is true, but not if you update it from an external source, and this was the reason for this discussion. I didn't start the performance discussion, but ... Agree with you. At the moment my parser needs 16s to parse XML and write it to the file for load. Expecting it not to become significant slower with sqlite3 output, that would mean (if vdr would not use in memory db) one could skip the load process since its submitted already to the vdr DB. For those concerned, putting the DB on a ramdisk, should give the best from both worlds + it could be easily connected from other applications to it. Anyway - result until now: 1.) Klaus doesnt like it, also does not like to make it possible to do it in a plugin. 2.) Some have a deep hate against any SQL solution. 3.) Some do like the idea - continue on point 1.) Well it was worth a try ... :( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Mon, 13 Dec 2010 00:00:27 + Tony Houghton h...@realh.co.uk wrote: On 12/12/10 22:33, Klaus Schmidinger wrote: On 12.12.2010 18:21, Steffen Barszus wrote: Having epg in a DB (sqlite,mysql) might also be nice. Definiteley *no* database in VDR! I've said it on many occasions, and I'll repeat it as many times as necessary! If you want to handle EPG data in a database, do it externally and feed the resulting EPG data into VDR via SVDRP. VDR stores data about the EPG, presumably indexes it somehow, and looks up information in it. That *is* a database. What's wrong with using an existing database engine? Less code for you to maintain, easier to access it with 3rd party tools, and if something like sqlite3 isn't quite as efficient as your code tailored for EPGs, does anyone still use a PC old enough that it would make any noticeable difference? That was my point in the beginning. Then: I want to see sqlite3 being less efficient on insert and fetch or memory consumption. I can not imagine it (prove me wrong! ;)). Last but not least i don't think any user would even notice any difference in behaviour. I think the low end would be PIII 700 (SMT7020s/S100) or ARMv5(sheeva/dockstar) recently. Anyway not feeling like fighting right now. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, 12 Dec 2010 23:33:13 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 12.12.2010 18:21, Steffen Barszus wrote: If we can be sure that between clre and adding the external epg no event comes into vdr by cEIT, means it can be ensured that this holds true for any stations external epg is used. I guess that should be pretty easy to establish. Simply blocking any EPG data coming from the transponders for a certain time (10 seconds, one minute? you name it) after a CLRE command has been received should do it. Once there is an EPG event in the schedule that has a table id of 0, that schedule would no longer receive any data from the DVB stream (until all its events have timed out and no further external events have been supplied, at which time it would fall back to the DVB EPG data). Fine with me :) On a side note to this, slightly OT: Thinking: What if a plugin could provide the EPG functionality for vdr ? EPG is a core feature of VDR (and DVB at large) and as such shall stay in the core VDR code. Besides, only the EPG data provided from the DVB data stream can support actual running status and thus VPS functionality I didn't say it should be removed - i just wanted alternative implementation for those wanting it. (no C++ expert!) I thought by e.g. declaring them as virtual functions, this could be archived. Or some other way .. i don't know In the long run it might be more useful if a more advanced merge from the different epgs source could happen at submission of the epg. The processing should happen in a seperate thread ( Having external epg for 18 days sums up to approx. 70MB, where vdr runs into emergency exit at the moment, if processed at once.) Current starting time from DVB might still be interesting, even if external epg is a lot better. You don't have to feed the whole 70MB into VDR at once. Do it channel by channel, and maybe with one channel day by day. That should allow enough time for VDR to keep its main loop alive. guess what i am doing. ;) - i just thought i could get rid of some workarounds over the time instead of adding more ... Having epg in a DB (sqlite,mysql) might also be nice. Definiteley *no* database in VDR! I've said it on many occasions, and I'll repeat it as many times as necessary! If you want to handle EPG data in a database, do it externally and feed the resulting EPG data into VDR via SVDRP. channels.conf and epg.data definitly are databases even if you don't name them as such. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Mon, 13 Dec 2010 12:14:48 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 12/13/10 11:49, Steffen Barszus wrote: On Sun, 12 Dec 2010 23:33:13 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 12.12.2010 18:21, Steffen Barszus wrote: If we can be sure that between clre and adding the external epg no event comes into vdr by cEIT, means it can be ensured that this holds true for any stations external epg is used. I guess that should be pretty easy to establish. Simply blocking any EPG data coming from the transponders for a certain time (10 seconds, one minute? you name it) after a CLRE command has been received should do it. Once there is an EPG event in the schedule that has a table id of 0, that schedule would no longer receive any data from the DVB stream (until all its events have timed out and no further external events have been supplied, at which time it would fall back to the DVB EPG data). Fine with me :) On a side note to this, slightly OT: Thinking: What if a plugin could provide the EPG functionality for vdr ? EPG is a core feature of VDR (and DVB at large) and as such shall stay in the core VDR code. Besides, only the EPG data provided from the DVB data stream can support actual running status and thus VPS functionality I didn't say it should be removed - i just wanted alternative implementation for those wanting it. (no C++ expert!) I thought by e.g. declaring them as virtual functions, this could be archived. Or some other way .. i don't know In the long run it might be more useful if a more advanced merge from the different epgs source could happen at submission of the epg. The processing should happen in a seperate thread ( Having external epg for 18 days sums up to approx. 70MB, where vdr runs into emergency exit at the moment, if processed at once.) Current starting time from DVB might still be interesting, even if external epg is a lot better. You don't have to feed the whole 70MB into VDR at once. Do it channel by channel, and maybe with one channel day by day. That should allow enough time for VDR to keep its main loop alive. guess what i am doing. ;) - i just thought i could get rid of some workarounds over the time instead of adding more ... Having epg in a DB (sqlite,mysql) might also be nice. Definiteley *no* database in VDR! I've said it on many occasions, and I'll repeat it as many times as necessary! If you want to handle EPG data in a database, do it externally and feed the resulting EPG data into VDR via SVDRP. channels.conf and epg.data definitly are databases even if you don't name them as such. Of course, but they are *simple* databases ;-) I don't want VDR to become dependent on some particular database software. And I like the fact that these files are plain readable text files. As allready stated - i thought that there is a way to replace in-vdr-functionality by a plugin implementing the necessary methods. Where i see the use of sqlite is that only parts of the data can be manipulated while vdr is running, user defined manipulations for epg bug fixing could happen as well, as possibly some relation between external epg and DVB events could possibly be implemented in the future or merging epg events from DVB with informations from somewhere else (speak eplists, http://thetvdb.com/). Furthermore the synchronization between different applications using the epg (i.e. XBMC) could be omitted since read access would still be possible. AND if the interface is abstract enough, having a real DB (postgre?) could help for client server environments having one EPG DB shared between all clients, not sending hundreds of MB around the local network for something simple like the EPG of just a video disc recorder. Right now you would need to fetch the epg from the outside, from vdr , try to merge it , pumping it back in pieces suitable for vdr to not influence user experience by blocking the main loop. This is some high level debating on thoughts about vdr - lets see what Jochen thinks of your proposal ... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On Mon, 13 Dec 2010 17:58:50 +0100 Denis Loh denis@googlemail.com wrote: Am 12.12.2010 22:27, schrieb Eric Valette: On 12/12/2010 22:02, VDR User wrote: (Btw, Klaus has made it clear VDR was never intended to be a server/client system. Maybe at some point it will address that need in a well-thought out way but as it stands now I'm not so sure it's a good basis for argument.) On the other hand, with streamdev server, vnsi server, we are approaching the client server mode. I think the real question for selecting a database are: 1) do I need a SQL interface, 2) do I need a client server model, sqlite is in use in 200MHZ mips router/ Tokyo/Kyoto cabinet can do less but consume even less. I was wondering why it must be a SQL DB. The new VDR requires at least one plugin namely sdff- or hdff-plugin So, defining an interface - for instance EPGProvider, with a basic implementation like the one which already exists - and let the user choose if he requires more power and extended functions to store and query the EPG, is a good option. Then he may install a EPGProvider plugin which comes with a sqlite-DB. Actually, sqlite may be good enough to be used for epg data. However I don't see it in the core. Klaus Point is (until now): - this wont go into a plugin - hand crafted database is enough My point is: - i want to have possibility for a choice with difference in behaviour/scale If i remember well the DVB devices have been planned to be plugins as well in the past - so how the cEIT scanner fits into the picture ? I dont want to put something i want down someone elses throat ... only choice. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Mon, 13 Dec 2010 22:19:45 +0100 Udo Richter udo_rich...@gmx.de wrote: Am 13.12.2010 11:34, schrieb Steffen Barszus: That was my point in the beginning. Then: I want to see sqlite3 being less efficient on insert and fetch or memory consumption. I can not imagine it (prove me wrong! ;)). Correct me if I'm wrong, but for sqlite you'll have to convert all these nice epg data structures into sql commands that need to be passed to the sql engine where an sql interpreter tears everything apart again for (possibly) on-disk storage, and for querying epg, the whole sql interpreter thing goes backwards again, or? I'm not too sure - as my DB experience is only with something bigger then sqlite. But i think, if done correctly, you have a couple of prepared statements which you can re-use with bind variables. Then taking into account that sqlite3 should be quite optimized for what its doing, and (which i would not want) you can have in memory db. Never under-estimate a native C/C++ coded data structure, at least if it's a smart one. Reading/writing to a tree or hash might be done before the sql interpreter even starts. Never underestimate the comfort you will get with not re-inventing the wheel ;). (not that the VDR internal structures are that impressive fast, though. I wonder how much it would gain by using C++ map and similar.) My point for suggesting sqlite was not only performance (which i can not estimate where vdr stands) - but also removing the blackbox of the in memory handling, and the handcrafted file format. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, 12 Dec 2010 16:19:00 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 09.12.2010 07:59, Steffen Barszus wrote: On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 08.12.2010 20:25, Jochen Dolze wrote: To be able using other epg sources with other event ids as from the broadcaster. Today i cannot add 14 days of external epg without patching. Why would you have to patch VDR for that? External event's by default have a table id if 0, which means they will never be overwritten by data from the transponder. You will get duplicate EPG entries if the time doesn't match Hmm, I see. So how about changing cEIT in such a way that it never overwrites any events in a schedule if the first existing event in that schedule has a table id of 0? If we can be sure that between clre and adding the external epg no event comes into vdr by cEIT, means it can be ensured that this holds true for any stations external epg is used. On a side note to this, slightly OT: Thinking: What if a plugin could provide the EPG functionality for vdr ? In the long run it might be more useful if a more advanced merge from the different epgs source could happen at submission of the epg. The processing should happen in a seperate thread ( Having external epg for 18 days sums up to approx. 70MB, where vdr runs into emergency exit at the moment, if processed at once.) Current starting time from DVB might still be interesting, even if external epg is a lot better. Having epg in a DB (sqlite,mysql) might also be nice. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On Sun, 12 Dec 2010 10:24:31 -0800 VDR User user@gmail.com wrote: On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. I strongly believe that there is a way to make it possible to replace/extend core functionality by a plugin - i can see that not everybody might want what i would imagine to be perfect. Still i did not wrote mysql alone, my thought was sqlite for normal use, and a real db (rather postgre ?) for networked/client-server use. sqlite i could imagine even in core - making the connection sql - mysql - mythtv - bad , doesn't have any substance at all. And talking about people who would leave vdr for the reason of what i'm talking about doesn't add anything either. I daily load a full set of epg from an external source, for the statistics: 70MB EPG data, containing 102.006 records, loaded daily. Extended by VDR-Seriestimer.pl called by epgsearch at the time of creating a timer. Wanting to say it can be easy or can have any complexity you want, for the latter, vdr current epg handling doesnt scale so well ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Sun, 12 Dec 2010 19:46:32 +0100 Eric Valette eric.vale...@free.fr wrote: On 12/12/2010 19:24, VDR User wrote: On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. Remember that for example in france the DVB-T stream EPG contains only the actual program and the next program. So it is hardly useable at all. external epg source is possible allready - i just think the merge and general handling could be improved :) You now have most other video recorder code that use xmltv one way or other (tvheadend, myth, ...). I like VDR because it is simple but OSD is so poor that it need to be integrated in something else (xine, xbmc) to provide a decent GUI and then you need a bunch of plugins (streamdev, epgsearch, ...). Plus there is almost no up-to-date documentation for plugins, or only in german, no centrailised source repositories because of the plugins are developped elsewhere... vdr-developer.org is a beginning :) and most new development is announced here too. So I second this post and think that decent epg is a basic feature for searching program and programmed recording based on epg and that dvb-t based stream is not the right way to go because it will contain very few infos in most countries. xmltv epg can be translated and imported into VDR now allready, there are a couple of other epg providing plugins and scripts as well, the main problem is available epg data possible to be fetched and translated. For those on linux, look at what qmagneto does and imagine it can talk to vdr to program recordings... I use it in cunjunction with mpalyer --dumpfile -dumstream to record IPTV streams. What about live plugin if the epg is imported into vdr ? It can handle epgsearch searchtimer, normal timer etc - so that allready exist to some extend :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 08.12.2010 20:25, Jochen Dolze wrote: To be able using other epg sources with other event ids as from the broadcaster. Today i cannot add 14 days of external epg without patching. Why would you have to patch VDR for that? External event's by default have a table id if 0, which means they will never be overwritten by data from the transponder. You will get duplicate EPG entries if the time doesn't match ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
2010/12/5 Klaus Schmidinger klaus.schmidin...@tvdr.de: On 05.12.2010 23:01, Jochen Dolze wrote: Hi, i would like to implement an parameter to disable the epg scan for (some) channels. I think an parameter in the channels.conf-file would be the best place. So, E0 means dont scan, E1 or absence of the E-parameter means scan the channel. What would that be necessary for? i guess its the same use case as noepg-patch and plugin. I only start investing my time if it has an chance to be included into the VDR. The channels.conf file shall contain only data that can be gathered from the transponder. I'm afraid the flag you're proposing isn't among that information. The question is if you maintain and synchronize 2 lists for one column of data or add optional parameter which can be maintained by vdr , a plugin or whatever. I would suggest one list to make it easier for everyone. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] lirc key reading to slow ? Buffer overflow ?
Hi !
i get these errors, once my remote is doing key repeats:
Dec 3 23:33:13 vdr vdr: [24629] ERROR: unparseable lirc command:
gy_Receiver-event-kbd#012b-Gyration_Gyration_RF_Technology_Receiver-event-kbd#01272
0 KEY_VOLUMEDOWN usb-Gyration_Gyration_RF_TechnoloKEY_VOLUMEDOWN Dec 3
23:34:14 vdr vdr: last message repeated 583 times
especially note the
usb-Gyration_Gyration_RF_TechnoloKEY_VOLUMEDOWN
and ...kbd#012b- (this should read usb-...)
is there anything forgot to reset ? A buffer to small ?
Just wrong how it is read ? In irw and xbmc there
seems no such issue, means the repeat just works.
i increased the buffers to:
private:
enum { LIRC_KEY_BUF = 500, LIRC_BUFFER_SIZE = 4096 };
which seems to make the error disappear, but its still incredible slow
(compared to other applications) in accept the keys. Can this be
improved ?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] dvb devices on demand patch
Hi ! i just read up again on this: http://www.mail-archive.com/vdr@linuxtv.org/msg13224.html Actually i think this would be also a good starting for a) save some energy - if DVB devices are not opened all the time, the driver has the chance to put it into standby saving some heat, energy and lifetime of the cards b) have a beginning of dvb device hotplug - if dvb devices are discovered on demand, its a good chance at a later stage to also add and remove cards on the fly. There is sure some notification required from udev to vdr so it can keep internal reference of the how many devices are there. Not that i could help in doing this - being aware it might take a while until its finished - but i still thought to share my thoughts, that this addition is not only usefull for shared frontends, but also for general usage. Hope the work on this is continued and possibly accepted by Klaus after some review and as work in progress. Kind Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
On Fri, 12 Nov 2010 23:10:23 +0100 Dieter Hametner dh+...@gekrumbel.de wrote: The live-plugin has support (contributed by third party developer) for SSL connections to its internal web-server. See the README file in LIVE for more details. The concept how LIVE works as plugin could be generalized to provide a 'generic' (SVDRP like) access via xml-http(s)-requests or via JSON etc. I like this idea a lot - additional advantage is that the access that way should be easier for the accessing applications. The general disadvantage of such an approach is, that it creates an 'officially unsupported' way to control VDR remotely. I mean it does not get 'standardized' by Klaus :) As long as more than one project is using this, it should be fine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
2010/11/10 Ludwig Nussel ludwig.nus...@suse.de: Udo Richter wrote: Am 09.11.2010 16:35, schrieb Matthias Wächter: You just re-introduce the old problem. Don't ever re-number. If you don't renumber any SVDRP client can be safe in assuming for (nearly) any time span to mean the same recording as the server when it updates a recording's schedule. In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? Don't recordings actually already have a unique id? It's the name of the directory they are stored in. ACK, keep it simple ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Wed, 10 Nov 2010 19:09:46 +0100 Andreas Brachold m...@deltab.de wrote: Hi, Am Mittwoch, den 10.11.2010, 12:23 +0100 schrieb Frank Schmirler: ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. Here I would agree with you. Guess a touch /video/.update would result in new IDs for all recordings. So one must be aware that if an ID is no longer available, the corresponding item has not necessarily been deleted. Why ? This is not even necessary ! Missing recordings should simple remove from list (LSTR) and new recordings should added at end of list. Anything else would not work with existing svdrp programs. But right now VDR can use only one connection at same time. From my point of view (xxv as svdrp client), I would not block the connection permanent. And I do not would to reread every time any recordings. So the problem is not the recording numbering (for what ?) , but the svdrp limitation to one connection. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Strange problem with one specific channel
2010/10/18 Eric Valette eric.vale...@free.fr: On 10/18/2010 11:45 AM, Magnus H wrote: Hi. The above applies for a standard unpatched VDR 1.7.16, even without starting any plugins. VDR simply won't record it. For the record: il have exactly the same problem with at least one channel in france. I can play the channle but each time I try to record it I get a 0 byte file. Haven't get time to investigate it yet. We got reported the same issue: https://bugs.yavdr.com/issues/143 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.16 no longer cleans del records from video.01, video.02...
On Tue, 12 Oct 2010 23:56:16 +0200
Klaus Schmidinger klaus.schmidin...@tvdr.de wrote:
Unless atinar or somebody else comes up with a fixed version
of this patch, I'll simply revert to the previous version.
find attached the patch.
- use lstat
- don't check if (n size) as it should be same
I have tested this and its working.
Steffen diff -urNad vdr-1.7.16~/tools.c vdr-1.7.16/tools.c
--- vdr-1.7.16~/tools.c 2010-08-29 17:03:08.0 +0200
+++ vdr-1.7.16/tools.c 2010-10-14 23:55:22.622829123 +0200
@@ -368,7 +368,7 @@
cString buffer = AddDirectory(FileName, e-d_name);
if (FollowSymlinks) {
struct stat st2;
- if (stat(buffer, st2) == 0) {
+ if (lstat(buffer, st2) == 0) {
if (S_ISLNK(st2.st_mode)) {
int size = st2.st_size + 1;
char *l = MALLOC(char, size);
@@ -377,14 +377,12 @@
if (errno != EINVAL)
LOG_ERROR_STR(*buffer);
}
- else if (n size) {
+ else {
l[n] = 0;
dsyslog(removing %s, l);
if (remove(l) 0)
LOG_ERROR_STR(l);
}
- else
-esyslog(ERROR: symlink name length (%d) exceeded anticipated buffer size (%d), n, size);
free(l);
}
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.16 no longer cleans del records from video.01, video.02...
On Tue, 12 Oct 2010 23:56:16 +0200
Klaus Schmidinger klaus.schmidin...@tvdr.de wrote:
On 12.10.2010 17:50, Lou wrote:
The patch was originally suggested by atinar at
http://www.vdr-portal.de/board/thread.php?postid=920661#post920661
and I adopted it with a suggestion from Urig.
Looks like nobody tested the patch in
http://www.vdr-portal.de/board/thread.php?postid=936545#post936545
otherwise this malfunction might have been detected earlier ;-)
Unless atinar or somebody else comes up with a fixed version
of this patch, I'll simply revert to the previous version.
Actually the only way the size of readlink() can
exceed the size of the filename, is if the encoding of the filename on
the linked-to directory is different, then the one of the original
file. Assuming UTF-8 has max 4 byte per character, int size =
strlen(buffer) * 4; should be fair enough. The length of the subtitle
should not matter, as the original filename should have the same
length as readlink if the encoding would be the same.
If you don't want to make assumptions, i think this is the culprit:
+ else if (n size) {
as n is equal size (as we read the size before )
So this :
+ else if (n size) {
+l[n] = 0;
+dsyslog(removing %s, l);
+if (remove(l) 0)
+ LOG_ERROR_STR(l);
+}
+ else
+esyslog(ERROR: symlink name length
(%d) exceeded anticipated buffer size (%d), n, size);
+ free(l);
should maybe be something like this:
+ else {
+l[n] = 0;
+dsyslog(removing %s, l);
+if (remove(l) 0)
+ LOG_ERROR_STR(l);
+}
+ free(l);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
I agree partially, for normal use its really ok allready. There are things which could be improved and not all problems are related to NVidia, but also to the state of the frontend plugins (namely xine and xineliboutput). So unstable is a littlebit to hard, stable doesnt fit either. 2010/10/13 VDR User user@gmail.com: On Wed, Oct 13, 2010 at 12:51 AM, Vesa ves...@nic.fi wrote: VDPAU with Xine looks promising, but it is still unstable. Yep, I know that issue is mostly on Nvidia driver side. It works great here and I think for most users. It seems only a small group has problems. Maybe the problem is with certain hardware combinations, I dunno. But saying unstable only applies to a minority of users afaics. Best regards ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.16 no longer cleans del records from video.01, video.02...
On Tue, 12 Oct 2010 10:10:07 -0700 VDR User user@gmail.com wrote: On Tue, Oct 12, 2010 at 8:50 AM, Lou tuxoho...@hotmail.de wrote: One of the changes you introduced in 1.7.16 does prevent the deletion of .del directories and the files inside of video.01, video.02 and so on. Only the del directories in video.00 with the symbolic links are cleaned up by the removing recordings thread. I guess it is caused by this change from 1.7.15: - Fixed following symbolic links in RemoveFileOrDir(). This bug has been confirmed by other users in vdr-portal. Any ideas what I can change in the code until 1.7.17 comes out? Assuming nothing like function params have changed, you could try just copying that function from 1.7.15. that should work but doesn't fix anything for the next version ;) (well thats not that has been requested, but it needs to be fixed anyway :) ) - question: is there a reference to the original problem that should be fixed by that ? I can confirm this.As told by Lou it should be the change in tools.c - RemoveFileOrDir() ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Arabic language EPG is inappropriately displayed
2010/9/9 Paul Menzel paulepan...@users.sourceforge.net: Dear Sami, [please just post normal plain/text messages [1–3].] Am Mittwoch, den 08.09.2010, 22:48 +0300 schrieb semsem85 sami: Is there any way to make the EPG readable in Arabic? Thanks alot. 3. Do you know other people having the same problems or did you find other reports on the WWW regarding the same problem? 4. Could you attach a screenshot so that the developers know what is going wrong exactly, please. 5. Could you attach `/etc/default/vdr`, please. 6. Could you please upload a test example somewhere so that developers can try to reproduce your issue and test fixes themselves. Unfortunately I do not know how to capture such an example though. 7. Are you using Arabic language for the menu of VDR too? Is it displayed correctly there? I think half of it is not necessary - question are: - does vdr have arabic translation allready ? - if not, ist it possible to have it, including right to left display - what is required to make vdr display the text correctly from right to left for languages requiring this This should be questions which someone here should be able to answer. Question to sami which remains: - What Locale you have set ? (ar_??) - Is the rest of the menus english or translated ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Subdirectories are missing
On Wed, 14 Jul 2010 17:41:47 +0200 Lars Bläser lblae...@mainz-online.de wrote: On 14.07.2010 08:56, Arno Esser wrote: corrected headline Am 13.07.2010 23:29, schrieb YUP: Wow, thanks for the tip, it's good to know! Yarema 2010/7/13 Arno Esser arno.es...@gmx.de mailto:arno.es...@gmx.de Hi, my 1.7.15 offer a nice feature. I have a subdirectory beneath video.00, that contains other mounted dirs. Initially after startup vdr only offers real recording in video.00. Only after a touch on video.00/.update ALL files in video.00 including the subdirectory are shown. Is that a mistake or a special feature? this feature is 6 years old ;-) I think this is a misunderstanding, i suppose Arnos Problem is not that the subdirectories appear, but that they don't appear at startup, but only at refresh of the recording list. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Edit timer/Timer conflict problem vdradmin/epgsearch
On Sun, 04 Jul 2010 15:09:31 -0700 Timothy D. Lenz tl...@vorgon.com wrote: adding the -v 3 doesn't show any more in the logs that I have seen, but another example of how changing the channel on the timer is messing something up: It picked up a show and set a timer I changed the channel to the local channel Now the local epg data has arrived and in vdradmin timeline it show the show in red showing it has a timer set. If I do a search, list the shows for both sat and local and gives the option to setup a timer for the sat channel only because the local is set. BUT, if you go to the timers page and click on the altered entry, it says can't find epg. What ever is off that causes that is likely also what is causing the OSD notices of timer conflict when there is none. Also, when in an OSD menu, the timers are listed on the right with text2skin/engima and below that it also says timer conflict. Hmm ... not really solution to the problem you try to debug, but could be a solution for you. Have you ever tried: a) using epgsync to get the EPG from the Sat you can not watch but has good EPG and copy it to your local station b) limit the search timer with a channels group to only the stations you can receive. Like that you should be able to use searchtimer you not need to adjust and no timers on channels you can receive. HTH Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] realy no idea? Re: problem replaying radio recordings in xineliboutput and vdr-1.7.15
On Sun, 27 Jun 2010 22:21:44 +0200 Halim Sahin halim.sa...@t-online.de wrote: Hi, It seems nobody is replaying radiorecording with xineliboutput and vdr-1.7.15. Can it be, that you have the radio plugin active ? This doesn't work here also with previous versions. Remove it and it works ... :-(. Regards Halim On Sa, Jun 19, 2010 at 08:53:55 +0200, Halim Sahin wrote: hi, Can someone please help? Vdr-1.7.15, xineliboutput from git and xinelib-1.2 from hg. When I try to replay a radiorecording i get the folowing in the tty running sxfe: xv_set_property: property=1, value=4 [4260] [demux_vdr] PMT changed [4260] [input_vdr] wait_stream_sync: discard_index 3929200 != curpos 3927320 ! ( diff 1880) [4260] [demux_vdr] PMT changed [4260] [input_vdr] wait_stream_sync: discard_index 5654100 != curpos 5277912 ! ( diff 376188) [4260] [demux_vdr] PMT changed I get No audio. When I replay same recording through xineliboutput's own mediaplayer it plays fine. Any ideas? BR. halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] externalplayer and xineliboutput plugin
Nobody an idea ? - Can somebody explain to me what a player with
PlayMode pmNone should do ?
This is the problem:
Apr 22 23:41:05 vdr vdr: [3204]
ERROR: /dev/dvb/adapter1/dvr0: Device or resource busy
If some application is started with external player
streamdev/vnsi-plugin with frontend xineliboutput produces below error
.. xine not
Thanks !
Steffen
Steffen Barszus wrote:
Hi !
I currently try to track down a problem of externalplayer and
xineliboutput.
The problem is, that if used with xineliboutput plugin and PlayMode
pmNone, one device is not available. With xine this does not happen.
May assumption is that here:
device.c:
641 m_PlayMode = PlayMode;
642
643 TrickSpeed(-1);
644 if (m_PlayMode == pmAudioOnlyBlack) {
645 TRACE(pmAudioOnlyBlack -- BlankDisplay, NoVideo);
646 ForEach(m_clients, cXinelibThread::BlankDisplay);
647 ForEach(m_clients, cXinelibThread::SetNoVideo, true);
648 } else {
649 if(m_liveMode)
650 ForEach(m_clients, cXinelibThread::SetNoVideo,
m_RadioStream); 651 else
652 ForEach(m_clients, cXinelibThread::SetNoVideo,
653 m_RadioStream (m_AudioCount1));
654 Clear();
655 }
An action is missing to take care of pmNone, i.e. to stop trying to
receive and decode something.
This is the Problem:
Apr 22 23:41:05 vdr vdr: [3204] receiver on device 2 thread started
(pid=2952, tid=3204)
Apr 22 23:41:05 vdr vdr: [3204]
ERROR: /dev/dvb/adapter1/dvr0: Device or resource busy
Apr 22 23:41:05
vdr vdr: [3204] receiver on device 2 thread ended (pid=2952, tid=3204)
This does not happen if i use xine, or if i shut down vdr-sxfe before i
try to use streamdev oder VNSI plugin.
My understanding is that the frontend device needs to do the required
action and let vdr know afterwards in order to free the device.
Would appreciate if someone with more understanding of the internals
could add his opinion here ...
Kind Regards
Steffen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] externalplayer and xineliboutput plugin
Hi !
I currently try to track down a problem of externalplayer and
xineliboutput.
The problem is, that if used with xineliboutput plugin and PlayMode
pmNone, one device is not available. With xine this does not happen.
May assumption is that here:
device.c:
641 m_PlayMode = PlayMode;
642
643 TrickSpeed(-1);
644 if (m_PlayMode == pmAudioOnlyBlack) {
645 TRACE(pmAudioOnlyBlack -- BlankDisplay, NoVideo);
646 ForEach(m_clients, cXinelibThread::BlankDisplay);
647 ForEach(m_clients, cXinelibThread::SetNoVideo, true);
648 } else {
649 if(m_liveMode)
650 ForEach(m_clients, cXinelibThread::SetNoVideo,
m_RadioStream); 651 else
652 ForEach(m_clients, cXinelibThread::SetNoVideo,
653 m_RadioStream (m_AudioCount1));
654 Clear();
655 }
An action is missing to take care of pmNone, i.e. to stop trying to
receive and decode something.
This is the Problem:
Apr 22 23:41:05 vdr vdr: [3204] receiver on device 2 thread started
(pid=2952, tid=3204)
Apr 22 23:41:05 vdr vdr: [3204]
ERROR: /dev/dvb/adapter1/dvr0: Device or resource busy
Apr 22 23:41:05
vdr vdr: [3204] receiver on device 2 thread ended (pid=2952, tid=3204)
This does not happen if i use xine, or if i shut down vdr-sxfe before i
try to use streamdev oder VNSI plugin.
My understanding is that the frontend device needs to do the required
action and let vdr know afterwards in order to free the device.
Would appreciate if someone with more understanding of the internals
could add his opinion here ...
Kind Regards
Steffen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-plugin and vdpau
Am 25.01.2010 07:37, schrieb Jussi J: Hi! So, what I ment when I said that I use vdr-xine with vdr-sxfe. Vdr have that vdr-plugin-xine loaded (of course) and then I call it using vdr-sxfe --video=vdpau xvdr://localhost you don't call xine plugin with vdr-sxfe with xine-plugin xvdr, thats xine with plugin vdr. vdr-sxfe/xvdr is plugin xineliboutput. -- Jussi J Mike Ditka http://www.brainyquote.com/quotes/authors/m/mike_ditka.html - If God had wanted man to play soccer, he wouldn't have given us arms. 2010/1/24 Petri Helin phe...@googlemail.com mailto:phe...@googlemail.com On Sun, Jan 24, 2010 at 7:44 PM, Stefan Taferner tafer...@kde.org mailto:tafer...@kde.org wrote: Am Samstag 23 Januar 2010 21:59:10 schrieb Jussi J: Sorry.. My fault.. It's vdr-plugin-xine.. :-) Anyway, now I can use it thru vdr-sxfe (but not using xine-ui; but that's not relevant) You need a patched version of the xine library, and xine-ui must use it, in order to get the VDR driver in xine. The VDR plugin for xine (vdr, used by vdr-xine) is included with xine-lib 1.2, if that's what you mean. But I still don't understand the configuration of the original poster, where he states that he is using vdr-xine's xine plugin with vdr-sxfe. That just doesn't make any sense. Using vdr-sxfe with xineliboutput's xvdr plugin for xine or xine-ui with vdr plugin would be much more sensible. -Petri ___ vdr mailing list vdr@linuxtv.org mailto:vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine vdpau not working?
Am 10.01.2010 09:38, schrieb Jiri Dobry: Hello, xine-lib must be patched, patch for this you can found on xine plug in directory. It add connection between vdrxine Except this xineliboutput plug in with external frontend (vdr-sxfe included in this plugin) it more useful a don't have problems with jumping on videosound. I have another problem when ANY version of xineVDPAU drop video frames. Some HW is better, some is worst. It happen when PC is under heavy load (example compilation on background). run xine (vdr-sxfe) with nice -n -20 help little bit but problem still exist. Worst situation is HD 1080i video on integrated Nv6300, it drop around 90% of frames. This chipset does not support any vdpau ... see http://ru.download.nvidia.com/XFree86/Linux-x86/190.53/README/appendix-a.html ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine vdpau not working?
Am 09.01.2010 21:16, schrieb Simon Baxter: Theunis Potgieter Said: I think it is your card that is the problem http://en.wikipedia.org/wiki/VDPAU shows that is should support up to VP1, however if you look at mythtv's guide: http://www.mythtv.org/wiki/VDPAU it starts only at series 8 and newer. It seems that your card can then only support xvmc for mpeg2 codec only. :( Buy a a new 8400 GS (old brand model name but new architecture G98 chip) as indicated here http://en.wikipedia.org/wiki/Nvidia_PureVideo I've tried it in my production machine now, which has this card: 03:00.0 VGA compatible controller: nVidia Corporation GeForce 8400 GS (rev a1) (prog-if 00 [VGA controller]) Subsystem: Giga-byte Technology Device 3463 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at ea00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (64-bit, prefetchable) [size=256M] Memory at e800 (64-bit, non-prefetchable) [size=32M] I/O ports at b000 [size=128] [virtual] Expansion ROM at eb00 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel ? Capabilities: [128] Power Budgeting ? Capabilities: [600] Vendor Specific Information ? Kernel driver in use: nvidia Kernel modules: nvidiafb, nvidia And while vdpau does work now, I get little CPU improvement (drops from ~60% under xv to ~45% on vdpau), there's some tearing during action scenes and some image freezing for a few seconds when switching from live TV to recordings which I've had to kill on occasion. Have you switched off compositing in the xorg ? Depending on your CPU - this is to high CPU usage still. I have below 10% at HD and around 5% or lower for SD while watching TV. Also denoise/sharpen of vdpau on SD content provides quite good quality picture even on SD. Currently I only have SD content to watch and my Sony Bravia 32V only supports up to 1360x668. Any point using vdpau? If you are fine with xv - but see above - the only time i came in that range IMHO was back at the days where i still used my Turion ML-30 at some of the HD stations (not all). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr shutdownskript - wrong time
VDR User schrieb: 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. Well, i can wait the 8 seconds (well with Bios maybe 15 sec) the machine needs to boot. I don't know what you consider a lot of power (here 60-100W depending on apps running - anyway it doesn't matter where you put the bar), but what you say sounds like i don't care about environment/ other people, which is provocative and sounds ignorant for some people at the place where i live. There are 8-10 hours where i sleep and another 8-10 hours where i am at work, which is at least 16 hours of 3W power consumption - i don't need the VDR running at that time, as long as my recordings are taken care off. If i should need it from external, i can wake it up by WOL. Think about it ! Anyway lets keep any further discussion about that off-list. Kind Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
Luca Olivetti schrieb: En/na Luca Olivetti ha escrit: The asus P5N7A-VM motherboard seems a good candidate, is its integrated 9300 graphics powerful enough for good deinterlacing? Mmmh, I hate to reply to my own message, but it seems it isn't available anywhere, at least here in Spain :-( I'm just at the same task at the moment. Vdpau enabled IGP motherboards except ION systems seem not to be available at all for some reason. Same for passive Nvidia GT220 cards (not yet available (Zotac Zone Edition or ECS)). Even if its german, this might give you a good overview: http://wbreu.htpc-forum.de/vdpaukompendium/leistungsvergleichgrafikchipsonboardchips/index.php To me that means, at decoding they are close to each other, but big difference at de-interlacing. i'm trying my luck at the moment with the passive cooled Gainward GT210, maybe later moving on to the GT220 once passive cooled models are available. It was told me that dual core CPU are preferable for OSD responiveness. Just to share a bit my findings from last days/weeks. I'm not quite sure if i will be able to keep the same noise level (nearly 0) with the HD components, but my plan is: C2D E7x00 Mainboard w/o IGP GT210/220 For AMD system it should be a K10 according to wb...@vdrportal.de, since the K8 models could cause problems with vdpau with CnQ enabled. HTH Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recommendation for new hd vdr system.
Luca Olivetti schrieb: En/na Steffen Barszus ha escrit: C2D E7x00 Isn't that overkill? (I mean, with hw accelerated people are using an atom) Yes it is, but * the CPU should have some potential for undervolting * configuration on speedstep i hope i can tweak I hope to get some potential for easy converting/whatever??? and have a not so hungry CPU otherwise (i read something like 8W idle which matches my current CPU which i used last years and it should idle most of he time assuming vdpau works as expected) Mainboard w/o IGP GT210/220 If I go this route (separate motherboard and graphic card) what about audio through hdmi? Any card will do or should I look for a specific one with some form of spdif pass-through? I don't have experience on this and its not a concern for me, but maybe still give you some facts: * the cards all have an audio pass trough, no connector though * the card reports to have an audio device * this audio device is not supported yet, but some people reported success to at last get it recognized with some patches, not sure if its working for anyone allready ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hulu for Linux
Michael Stepanov schrieb: On Wed, Nov 11, 2009 at 3:44 AM, Timothy D. Lenz tl...@vorgon.com mailto:tl...@vorgon.com wrote: I already have debain linux/vdr setup. 64 bit on my system and 32 on my dads. I don't want to rip it all out and start over with another flavor of linux. Then XBMC will help you ;) Here is one way to integrate VDR and XBMC using streamdev plugin - http://blog.mymediasystem.net/avchd/xbmc-on-karmic-with-vdpau-and-vdr/ There is also another way without streamdev, which is better as people talk. And then, how does it related to the OP question ? Michael Stepanov wrote: Hi Timothy, You may try LinuxMCE - http://linuxmce.com, which includes VDR, MythTV and now Hulu :) Or you can try XBMC+VDR On Sat, Oct 10, 2009 at 6:58 PM, Timothy D. Lenz tl...@vorgon.com mailto:tl...@vorgon.com mailto:tl...@vorgon.com mailto:tl...@vorgon.com wrote: Hulu now has a linux interface. And it seems MythTv can use it. what about vdr? Can it be done without installing a desktop? http://www.nvnews.net/vbulletin/showthread.php?t=139868 To my understanding, yes and no, depends on what you understand to be a desktop. You need X for it and something to launch it. (Flash interface) + Flashplayer (i believe Gnash can't do it yet ?) The XBMC could be your Desktop and i believe, what the answers before trying you to say is you could launch Hulu Desktop from within XBMC (not proven as i can't - neither XBMC here yet, nor can i use hulu) So whatever else, you need X and display X on your TV. HTH Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] vdr-remoteosd-0.1.0 and vdr-svdrposd-0.1.0
Mika Laitio schrieb: I just published new releases of the plugins remoteosd and svdrposd (formerly svdrpext) on http://vdr.schmirler.de. The most important changes are the overdue gettext support for remoteosd and a major speedup of the remote menu in combination with the new svdrposd plugin. The remoteosd plugin provides access to the menu of an other VDR. Remoteosd relies on the svdrpservice plugin, which is also available from my website. I renamed the svdrpext plugin to svdrposd. The plugin publishes the textual contents of the OSD menu on SVDRP. In order to access the menu of a remote VDR using the remoteosd plugin, svdrposd or its successor svdrpext must be installed on the remote VDR. Hi, I got interested in from your plugins and tried to read throught your web page to get more info. So if I understood correctly the svdrpservice plugin provides the highway howto communicate from client to vdr server. But after that I get a little lost what are the cases where I should use your plugins... I mean currently I have 1 vdr server with dvb-t and dvb-c cards, xineliboutput server and streamdev server plugins running on it. Then from other client computers I can use either mplayer or xineliboutput client (vdr-sxfe) for connecting to this server for watching the tv. Currently my setup has however a that kind of limitation that all vdr-sxfe clients are forced to watch the same channel and whenever any of the clients change channel, the channel will be changed also to every other vdr-sxfe clients. I have read this could be somehow be avoided by running multiple vdr servers on the server machine and then forcing each client to connect to own vdr server port... Are your plugins meant for solving a that kind of multiple clients want to watch different channel problems or for which purpose your are using these plugins? My understanding of how you could do the setup, and how exactly this plugins can help you: You have streamdev-server and svdrpservice/osd plugins running on the server. You have running streamdev-client and remote-osd, remote-timer and whatever else plugin running on the client(s) The client would carry the xineliboutput plugin and you connect on the client machine to the client machine vdr. The streamdev provides the tv cards to the clients. The remote timer plugin enables you to create timers and more on the server, the epgsync lets you sync the epg, so clients don't need to do epg-scan (which could hit your server hard if 1 server , multipke clients). The Remote OSD Plugin enables you to have the server OSD on one of the clients to do configurations etc pp. So in the end you get a client server vdr which behaves very near like a few standalone vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dual DVB-S2 Tuner cards
Theunis Potgieter schrieb: Hi guys, do any of you have information with regards to Dual DVB-S2 Tuners on a PCI or preferably a PCI-E type card working on vdr? I did have a look on http://www.linuxtv.org/wiki/index.php/DVB-S2_PCIe_Cards But only mentions 2 and they seem to be a rare find. Well at least where I live. Does anybody else know of working DVB-S2 cards for Linux? I did find plenty of Hybrid/Dual type cards but they seem to be supporting DVB-T + DVB-S/S2 and not even both at the same time :( Any advice would be appreciated. There is a device called Media-Pointer MP-S2 DVB-S2 Twin Tuner matching your requirements. The linux driver has been started to my understanding, but is not yet working fully, from what i understand from http://www.vdr-portal.de/board/thread.php?threadid=87049 (german, some guys which have the card) - what you can read from where is that linux support for the card is at least planned and partially finished. The card seems to be pretty new. So working on vdr seems not yet been fullfilled. Maybe you can check on DVB mailinglist for more details. Kind Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Editing usability
Udo Richter schrieb: On 09.05.2009 22:04, Klaus Schmidinger 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 Yeah, but was it 7 or 1 for jumping? Does cutting start on 2 or 8? Don't get me wrong, I can do this blindfolded in my dreams. Its just not as obvious and easy to discover for beginner/infrequent users as the rest of VDR is. Please PLEASE don't change that to color keys - the number keys are perfect for taht. What i do like is the help page idea - just that there is a possibility to quickly show a keymap like written above by Klaus, next button press switch it off. Should be easy and works. Someone tested the aide plugin ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
Gerald Dachs schrieb: 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. second this ... If it gets deleted after a certain timeout, you'll probably turn this off once you lost such a recording for the first time, because something came up that kept you from finishing viewing it in time. Okay, something to think about. pausing is pausing not recording. recording is recording (what a wisdom :D ) - How to handle such a recording if it's not in the list of recordings? Maybe you find the recording to be so interesting that you want to keep it - no chance if it doesn't appear in the list. Press the record button on the remote and the complete recording till now will go into the list of recordings. Second this. How about another type beside .rec and .del for this. To make it clear i'm just for not handling pause as a normal recording if you stop pause its gone except you press record in the pause replay which will rename it to a normal recording. Good idea. Thumbs up! Kind Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Fwd: Re: let vdr ignore non vdr directories ?]
Peter Dittmann schrieb: I can't see any evidence for this symlinks, and I don't know a reason for this. The vdr gets told via the option '-v /var/lib/video.00' where the video dir is located. But you see what I'm pointing to. The distries are usually mounting the partition directly and then use the xxx/video[.]xx directly. Using the previous suggestion would mean the path tree of most of the distributions need to be somewhat different. E.g. like this: /var/lib/vdr |- video.00 | |- video | |- somthing-else | |- video.01 |- video |- somthing-else-2 ... So better suggestion for the distri maintainers would be to use the \mnt tree for mounting any partitions. Then always create a (dummy) directory on the video partitions (video or vdr). Then linking this mounted directories as /var/liv/video.xx. /mnt/video.00 -- /mnt/[h|s]d[a-z][0-9] /mnt/video.01 -- /mnt/[h|s]d[a-z][0-9] ... /var/lib |- video.00 -- /mnt/video.00/video | |- video.01 -- /mnt/video.01/video ... Quite a difference to what is now. Hopefulls the distri maintainers read this and make some sensible changes to the standard path tree to make VDR's video directories collision free with temp directories for burn ... Obviously the distries are not based on usual use configurations currently for how to handle the huge temp files for some of the tools for burning. This make life more complex and will cause a lot of individual effort to modify the installation after the distribution is installed. You can individually do a lot. It's just a matter of knowledge and ideas. But as I assume that currently 80..90% of VDR users are starting from a distri rather than LFS this is a field issue. And obviously the safe mounting suggestion for a single disc system wasn't that obvious. So there is room for improvement ;-) Yes agree - as i started the topic i need to admit i run into it not getting this idea even though i even played around with bind mounts short before ;) For modern distribution i would suggest to use bind mounts however and mount point would be more likely /media/. I think this is cleaner. Mounting the discs/partitions the way its done is the obvious way i think, and having a directory of its own and doing all kind of things to the content therein is pretty vdr specific. So the suggested (and sensible) recommendations are in fact not that obvious. This also shows that there is a solution/recommendation to create some .do_not_touch files in possible empty directories required by plugins to make them not-empty this way, to ensure vdr to startup with these plugins (dvdswitch, burn, etc) I'm pretty sure it will now spread the word ;). For me the issue is solved with that and hope ctvdr , easyvdr etc will default it to something like that :) I have to do some updates to a few installations now to change it accordingly. Kind Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Fwd: Re: let vdr ignore non vdr directories ?]
VDR User schrieb: On Tue, Apr 21, 2009 at 11:08 AM, Steffen Barszus st_bars...@gmx.de wrote: the content therein is pretty vdr specific. So the suggested (and sensible) recommendations are in fact not that obvious. This also shows that there is a solution/recommendation to create some .do_not_touch files in possible empty directories required by plugins to make them not-empty this way, to ensure vdr to startup with these plugins (dvdswitch, burn, etc) The most sensible thing to me would be to ask the authors of those plugins to make the directories it uses user-defined instead of hardcoding VDR's recording directory, or change them in the source. It seems backwards to change VDR's core behavior because of poor plugin design. That's just my 2 cents, maybe I've missed something though. You have missed something indeed. Don't assume poor implementation without checking the facts or even read all of them. There are different type of users, usages, requirements out there then you might think. This is going from 300Mhz / 40GiB to 2x3Ghz / 8TB harddisk space - LFS to Linvdr and everything inbetween. So keep calm and play nice. We talked about distribution defaults here. Nobody is asking anymore for change in vdr. These plugins do have configurable directories. They have in common, that they need plenty of space. The distribution defaults are as example as below And thats where the problems started. Just looked it up: dvdswitch: # Path to DVD images # (default is /var/lib/video/film/dvd) # # --imagedir=PATH burn: # use DIR to store ISO images # (default: /video/iso) # This is ctvdr/e-tobi mix (still 1.4.7 here - might have changed in the meantime) And i don't blame anyone - i just hope next version of debian/e-tobi,c'tvdr, ubuntu, EasyVDR insert your favourite here will pick up the suggestions made :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Fwd: Re: let vdr ignore non vdr directories ?]
Ville Skyttä schrieb: On Tuesday 21 April 2009, Peter Dittmann wrote: So better suggestion for the distri maintainers would be to use the \mnt tree for mounting any partitions. I disagree, /mnt is system admin area, not something distros should touch. http://www.pathname.com/fhs/pub/fhs-2.3.html#MNTMOUNTPOINTFORATEMPORARILYMOUNT FHS might not be catering for vdr yet ;) - /media is not suitable as well - and /srv might be for the video directories, but not for the mounted partitions ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr directories
marti...@embl.de schrieb: Can somebody clarify please. Does vdr need simply a directory of its own for recordings (in my case I have assigned it /media/video/vdr ) or a unique mount point (in which case I would have to repartition since I have a 1TB hard drive mounted on /media/video but have other folders in /media/video (avi, mpg) Will vdr try to go through /media/video/avi (to my dismay if that is the case!) or just /media/video/vdr only /media/video/vdr vdr will look on - so no problem for you. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Fwd: Re: let vdr ignore non vdr directories ?]
Matthias Schwarzott schrieb: I thought bind mount does work on even older kernels, still shouldn't a symlink work too? Need to re-check - guess i mix something here. Some bind mount features only start working properly at 2.6.26+ (bind mount ro, move etc). Bind mounting readonly some directory makes full disk read only, but thats not required anyway here. So I did setup lvm on my harddisks and made my video partition a logical-volume that can span as many harddisk as I let join the volume group. Still some time ago I had a setup using vdr's own support for multiple disks as you use it. On LVM how does one know which disk will be used ? thats the main advantage - that all handling data is on slow, low power, silent, cool harddisk, real data gets on the big ones. So I suggest you mount your disks somewhere else (like /mnt/large1 /mnt/large2) and then do bind mounts or symlinks from /var/lib # mount /dev/disk1 /mnt/large1 # mount /dev/disk2 /mnt/large2 # mkdir /mnt/large1/video # mkdir /mnt/large1/video # mount --bind /mnt/large1/video /var/lib/video.01 # mount --bind /mnt/large2/video /var/lib/video.02 Will test that ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] let vdr ignore non vdr directories ?
Hi all! is there any way to let vdr ignore any directories which do not belong to it ? What i have seen is that vdr is recursive checking all directories even on second and third video directory. If the logic is that all needs to be in video.0 directory and its subdirectories and symlinks will be required to let vdr find the recordings, it should not check the other video directories. Background: I accidently remounted /proc vdr readable in video.01 directory for doing some chroot. The result is that i lost 3 recordings. The log has grown to a few GB in no time and vdr made the system be occupied by that job. Those i think it should be enough to scan video.00 and the symlinks therein or check for some .vdrignore file before traversion. The first solution should also speedup re-reading recordings. Hope i did not missed a change in behaviour in newer vdr versions as i am still using 1.4.7 Think there might be others as well that are using the big disks for other space consuming things - nobody else run into this ? Thanks and kind regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: Germany/IPTV: Watching private stations on PC?
Paul Menzel schrieb: Dear everyone, some German providers offer IPTV. Public stations are broadcasted using DVB IPTV/multicast(?) [1][2] and I can watch them using a special port of the provided modem and for example mplayer. [1] http://www.ard-digital.de/14026_1 [2] http://www.unternehmen.zdf.de/index.php?id=248 Looks like you are searching for the iptv plugin: http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ http://www.vdr-wiki.de/wiki/index.php/Iptv-plugin Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] noad for VDR 1.7.x
Peter schrieb: There are some discussions going on on the german VDR Portal: http://www.vdr-portal.de/board/thread.php?threadid=85297 Thanks for the pointer! I managed to use the patch against noad 0.6.1 (0.6.0 does not compile on my system due to lack of deprecated ffmpeg functions). It works but often does not exit and continues to consume memory so I have to kill such noad processes manually. I do not speak/write German so am not sure where is the best place to ask for help? Just ask in english in the thread mentioned. Or use the International Part there - and make a post in the mentioned thread pointing to it - what ever you think fits better. :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Forthcoming VDR Release To Support VDPAU (???)
VDR User schrieb: I've been using vdpau-enabled xine in VDR-1.7.4 (via xine-0.9.0) for some time now so if he's only saying it's possible then that's old news. But if he's saying vdpau will be supported in VDR core, then that's pretty big news in my opinion (although I don't believe that's the case). Think thats some bad wording. It should rather have been (changed part between **): This morning we find out from Stefan Huskamp that a new *EasyVDR (Linux VDR Distribution (Video Disk Recorder http://www.cadsoft.de/vdr/))* release is coming soon and it too will feature support for the Video Decode and Presentation API for Unix through its use of the Xine library. Furthermore i hope that thisis not blocking the efforts of AMD/ATI and Intel (or better is pushing this two) and that in the end something along VA-API is being used. Either way I'm glad to see VDR getting some promo! :) For sure - better if it would have been more precise ;) Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vote your VDR patches
VDR User schrieb: On Fri, Feb 27, 2009 at 2:25 PM, z...@zulu-entertainment.de wrote: we have start a poll at http://www.nmsweb.de/vdr/patch.php where you have the possibility to vote for your favorite VDR patches. How about the voting text in English Alltough it would have been preferable to have everything in english, if you care about it and want to vote: 0 means not required at all, 5 means absolutly required/very important. Kind Regards Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Broadcom BCM70010/70012 - AVC/VC-1/MPEG High-Definition Video and Audio Decoder for PCs
Goga777 schrieb: http://www.broadcom.com/press/release.php?id=1161576source=home PCI Express and Linux supported / according to the press release / doesn|t sound that bad. Question is if the support will binary only again / or if thez learned in the meantime. We'll see :) Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UPnP/DLNA server plugin?
Teemu Suikki schrieb: 2008/4/29 Steffen Barszus [EMAIL PROTECTED]: There is a good UPnP server available for linux, called Fuppes: http://fuppes.ulrich-voelkel.de/ not tried that - found mediatomb to look more interesting I installed mediatomb now too. It is far easier to setup than fuppes, and has some extra features like http streaming.. But still doesn't work any better with PS3. :) It could be that the mime type is flagged wrong ? Think its outside vdr not that usual to stream mpeg2-ts around ;) The TG100 is streaming it just fine, but every now and then it displays the TV stream like radio (with OSD :( ) Did you try to change the type in the webinterface of mediatomb allready ? I wonder why the http streaming doesn't work, PS3 just reports some server error but logs show that it has actually connected to the stream just fine. Maybe also the IRC of mediatomb might help ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UPnP/DLNA server plugin?
Teemu Suikki schrieb: Has anyone written a direct UPnP/DLNA plugin, to stream out VDR recordings and live TV to PS3 or XBOX 360? no something like that doesnt exist. I have used a cron to fetch the m3u of the channels list onto harddisc and mediatomb to serve it with upnp to my tg100. To my knowledge they are supporting PS3 and the latest version is also supporting transcoding - so this seems to be a good start. Missing is a recording list which can be done with some sort of hack with the streamdev plugin as well (greating a file with the urls for recordings and streamdev externremox to serve the files. IMHO this would be a logical extension to the streamdev plugin. :) see above - yes. This and the possibility to have some notification between mediatomb and streamdev-server this would be really nice. Someone would need to do some work on the meditomb side ideally to write a custom import script to display it properly in the structure -according to mediatomb docs this should be fairly There is a good UPnP server available for linux, called Fuppes: http://fuppes.ulrich-voelkel.de/ not tried that - found mediatomb to look more interesting Fuppes can be used to stream VDR recordings, but so far I haven't been able to get live video to work.. And even with recordings you need to use transcoding because PS3 doesn't like MPEG-PES. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
Seppo Ingalsuo schrieb: Here is something about my HTPC setup, hopefully gives some help or food for thought to set up your system [EMAIL PROTECTED] wrote: To go back to the subject, gdm and kdm allow you to autologon an user. The next step would be to run vdr from .xsession for ex. For gdm, add these lines to gdm.conf to login vdr automatically AutomaticLoginEnable=true AutomaticLogin=vdr I'm using vdr (sxfe frontend from xinelibout plugin, xine plugin can be used identically) from Matchbox window manager. It provides user experience kind between set top box and normal Linux desktop. All applications are full-screen and all wm operations are possible from keyboard that can be mapped to be controlled from lirc with irxevent. In addition to vdr it's nice to run e.g. Google Earth for couch traveling or Gcompris for kids. Those require a RF keyboard/mouse joystick for controls. Sounds better than sxfe only without login Regarding Fullfeatured card if i would have a LCD/TFT TV and would start now with vdr i would think hard about which way to go :) Yours with the added value, possibility to run emulators, games etc or having unproblematic and superb picture quality with the TT FF card (which got cheaper lately btw) (no hassle with deinterlace/scaling) Guess this depends on the main use of the box - and if you want to go for hdtv Matchbox looks really interesting ! Looks like even a OnScreen Keyboard is included :) Why did i never heard about it before ? :D Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ATSC
Timothy D. Lenz schrieb: Any chance we can get ATSC tunner card support with the next branch of vdr? In 1 year from today it will replace all analog TV broadcast in the US. Think that depends solely on what interface these cards - are they using linux-dvb api ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VideoCD Plugin 0.8
VDR User schrieb: On Dec 12, 2007 4:59 PM, Halim Sahin [EMAIL PROTECTED] wrote: Hi Vdr User, You don't know video cd's? ?? If he means VCD's, sure, but then what would be the point since playing them (and much more) can be done via the mplayer plugin? Is this plugin meant to be an alternative to that or something? That is a dedicated (S)VCD plugin like dvd for DVDs . And it exists since ages allready, a lot longer then the mplayer plugin solution popped up. Only because it does something which another plugin can also do, it doesn't become pointless ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ct 26/07: TT FullFeatured h264?
[EMAIL PROTECTED] schrieb: In ct 26/2007 p150 it is said that full featured cards allmost vanished after almost everybody had more than enought cpu power available. But they see a renaissance since even a lot of new pc are not strong enough for h264. They state that Techno Trend has announced such an aktive card (defined before as one with hardware decoder) for next spring! Does anyone know more? Yes - see (german) vdrportal in HDTV section - discussion is allready ongoing for more then a year now i think. Means that it comes soon to market allready since a while. Reel extension is some steps further allready ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD setup
rjkm schrieb: Igor writes: I have CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (Family: 6, Model: 15, Stepping: 6) and picture of x264 recording VIDEO: [avc1] 1280x720 24bpp 23.976 fps is just perfect, but sound comes out about 0,2 second too early with xine. With my other machine AMD Athlon(tm) 64 Processor 3400+ can not play those file with-out heavy problems, totaly under power CPU for that kind of playback. My friend has a configuration hard: Asus P35 + Intel 2160 @ 3GHz + 2GB ram (@800MHz) + SATA disk + ATI2600XT 256MB + TT3200 soft: debian testing (lenny) kernel 2.6.22-2-686 V4L-dvb = Multiproto - 26.10.07 xorg video driver = ati 8.41.7 (fglrx) vdr 1.5.10 + vdr-1.5.10-dvbs2-h264-syncearly-framespersec.diff xine-0.8.0 plugin ffmpeg-cvs from 08.11.2007 xine-lib-1.2 from 8.11.07 xine-ui from 8.11.07 and can see the h.264 dvb-s2 channels with average 60% CPU load. What kind of streams are these? What bitrate and resolution? For real comparisons we will need to specify the exact stream parameters. If sombody has some links to files, I can run tests on a decypher chip. Then we can compare that to the load on different CPUs. i would really like to see this - allthough i can't help in finding files. Even a C2D + RAM +Video card @60% load for average TV viewing sounds crazy to me - so i would prefer HDe as well - as soon as it is available and some people are using it. At the moment with my CRT TV there is no real use for it anyway ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
VDR User schrieb: On Nov 19, 2007 2:40 AM, Jan Exner [EMAIL PROTECTED] wrote: Why would you bother when you can buy something way better faster for cheap these days? Why would you bother updating when it works just fine? And even the cheapest system I could buy today is still more expensive than keeping what I have now. Well obviously when your ancient pc can't handle new things such as h264 decoding and HDTV, and no manufacturer is willing to waste their money making a hardware decoder card, I would say it's not working just fine as you claim. Sorry, a small handful of people using ancient pc's for dvb is not even vaguely enough for manufacturers to create h264 hardware decoder cards. And even if they did actually bring one to market, meaning you can BUY it and not just look at it on a website, the cost would be too much. I'm sure it seems strange to you that people are using decoder hardware if the CPU can easily do it. BUT All people having an FF card or dxr3 or em84xx are using exactly something like this. Count users using such a setup and count people using softdevice etc pp setup, i'm sure the people with soft decoding are the minority (or at least lesser then the first group). If there's such a market for hardware decoding, where are all the cards? How come manufacturers aren't jumping at the chance to capture the profits from people like you with old slow pc's in need of such cards? marketing doesn't allways recognize market demands, but tries to create demand for their ideas ... As i said it's obvious that this idea sounds strange to you - but that doesn't mean that its a bad idea. I don't have exactly an ancient setup (Turion ML30+500MB RAM) but why i should burn CPU cycles all the time for wathcing TV if a hardware card can do it far more effecient ? And the power left over can sure be used for streaming, converting and so on. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transcoding video on-the-fly ?
Marco Goebenich schrieb: Hi! See the -r parameter of vdr. together with epgsearch plugin which should be able to create a timer for each show on one channel with the correct search timer settings. Regards Marco jussi salmi schrieb: Hi gurus I'm newbie with VDR (version 1.5.10/1.5.10) and I have a few question about it. I need to record one channel 24/7/364 and I would like to record and transcode on-the-file videos using one-file-per-show basis. Because the channel is scrambled I need vdr to handle the CONAX in this case. So my idea is that writing a perl script, it would be able to 1. read the epg-data 2. make a recording list 3. start recording at the time show will start 4. hand over the video for transcoding by mencoder or ffmpeg (for exsample: vdr | ffmpeg -i - -b 500 -vcodec xvid MULHOLLAND_DRIVE.m4v) So, is't possible to use any transcoding program by vdr ? Please, any help would be higly appriciate -Jussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2 dvb-s cards with different feeds
dom.plu schrieb: Hi This patch has the same poblem than lnbsharing : if you installed the same card (like u have 2 SS2) , you are not sure of which one with be the first or second when the system will startup , with different sat card model you can use udev/ scripts on insmod to assign dvb device number You should also be able to to that with the pci slot as indicator - not sure though if this was just recently added. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Not good behaviour from vdr
Walter Koch schrieb: Moin, The solution with three options sounds best: restart always, if no other (working) recordings, never. But this doesn't stop the VDR started to restart itself every minute- problem completely. If there was already one emergency exit shortly before and the stream didn't come back, it doesn't help to restart again. And again. And again ... So an additional parameter Minimal time between emergency exits (minutes) IMHO would help Maybe a solution for all the ideas in here ? Let vdr call a command and decide based on exit status ? This could be simply set to /bin/false for never restart or any sophisticated logic for everything else ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV future for VDR
Igor schrieb: Be patient .. in 2010, you will have more HTDV on it's way. During last two years, HDTV was a hype, but it becomes much more mature and DVB-S2 standard states H.264 as codec. 76 hdtv channels you can watch today. http://ru.kingofsat.net/hdtv.php good results If you have a dozen of sattelite dishes - partially more then 3m big - and friends all over the world (paytv subscriptions) ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Convert video clip to .vdr format
VDR User schrieb: On 9/16/07, Clemens Kirchgatterer [EMAIL PROTECTED] wrote: Anssi Hannula [EMAIL PROTECTED] wrote: Dick Streefland wrote: VDR User [EMAIL PROTECTED] wrote: | I think a better idea is to just install a codec that plays | whatever format your camera videos are in and use the mplayer | plugin. But I have a rather underpowered VDR machine with a full-featured DVB-S card, so I really need to use the hardware MPEG decoder. Mplayer can play MPEG files using the hardware MPEG decoder without re-encoding. but it's NOT an mpeg file he wants to play! so we're back to where we started from. ;-) Right, it's M-JPEG format. No conversion should be necessary to play his files, just installing the proper codec and using the mplayer plugin should be fine. There is FFmpeg MJPEG decoder. Here are some packages to explore: SO conversion IS needed ! It needs to be transcoded on the fly to mpeg1 at least to be usable in his setup - which is impossible because the vdr is not big enough. But the solution got allready proposed. Any mpeg1/2 + genindex should be fine ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Exist: windows media player that plays unaltered vdr files?
Torgeir Veimo schrieb: Subject says it all. It's just way too much work to transcode files if I want to send a clip to friends. VLC and mpui can do that. Also some direct show filter exist that make it possible to play unaltered files. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
