Re: [vdr] Request: E parameter in channels.conf for epg scan
On 12 December 2010 23:50, Eric Valette wrote: > > On 12/12/2010 20:29, Steffen Barszus wrote: > >> external epg source is possible allready - i just think the merge and >> general handling could be improved :) > > If you try to prove everything is possible via plugin yes. Vdr could even be > simply a plugin loader as someone else suggested. The problem for the end > user is how many packages do he have to install and configure to get a decent > functionality and how easy is it. > > for most users compiling from sources is simply too complicated. I tried > packages from yavdr and they do not work for me. I have been forced to use > the debian pacakging and remove patches to correctly have HD TV via XBMC. Gave Gentoo a try? Once you updated vdr, all you need to run on Gentoo is: vdrplugin-rebuild all > > >> vdr-developer.org is a beginning :) and most new development is >> announced here too. > > I rarely found anything useful at vdr-developer.org except maybe a small > description of some plugins but almost nothing about their status if they are > actively maintained, the git location and so on. Even the description of > channel.conf is quite innacurate. In fact this list is the almost unique > source for information. > >> 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. > > Did you try to use it recently. The xmltv to vdr perl script is unmaintained > and obsolete... On 17 March 2010 07:59, william wrote: I have made some other changes. and also got an update from Rob Davis. which added ratings and credits see: http://cobradevil.org/downloads/xmltv2vdr-1.0.9.tar.gz Thank you! With kind regards William van de Velde > >> 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 :) > > live plugin needs streamdev and epgsearch to function right. So again it is > not basic VDR. Plus, in France in never managed to find anything useful via > the various search feature. > > --eric > Theunis ___ 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
> 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. Gerald ___ 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 12/14/2010 10:13 AM, Theunis Potgieter wrote: Gave Gentoo a try? Once you updated vdr, all you need to run on Gentoo is: vdrplugin-rebuild all I'm not going to try gentoo. However, if this works that is great alltough you should probably recompiled vdr depending on the plugin code you install? On 17 March 2010 07:59, william wrote: I have made some other changes. and also got an update from Rob Davis. which added ratings and credits see: http://cobradevil.org/downloads/xmltv2vdr-1.0.9.tar.gz Thanks for the pointer. However, the vdr pages do not point to it and this was my point. -- eric ___ 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 14 December 2010 10:49, Eric Valette wrote: >> On 17 March 2010 07:59, william wrote: >> I have made some other changes. and also got an update from Rob Davis. >> which added ratings and credits >> >> see: http://cobradevil.org/downloads/xmltv2vdr-1.0.9.tar.gz > > Thanks for the pointer. However, the vdr pages do not point to it and this > was my point. Yeah it was on the mailing list as part of an ANNOUNCE post, but I think Klaus was asked to upload it to ftp://ftp.tvdr.de/vdr/Tools/ (which is currently only showing 1.0.7) and hasn't got around to doing so yet. At the time I planned generate a github repo with all the history of xmltv2vdr and I did do it at https://github.com/oldmanuk/xmltv2vdr back in April, but at the time I was still learning git and it hasn't really been properly tagged how it should be. I'll probably redo this at some point to make it a bit better. I also made my own updates to xmltv2vdr to use the episode numbering that is now present (at least on the UK Radio Times data) to put it in the subtitle, so that I end up with search timer recordings like 'Spaced~s02e01-Back' ___ 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 14 December 2010 12:49, Eric Valette wrote: > On 12/14/2010 10:13 AM, Theunis Potgieter wrote: > >> Gave Gentoo a try? Once you updated vdr, all you need to run on Gentoo >> is: vdrplugin-rebuild all > > I'm not going to try gentoo. However, if this works that is great alltough > you should probably recompiled vdr depending on the plugin code you install? You only need to recompile vdr if a new plugin requires vdr to be patched which Gentoo also handles by introducing flags when you initiate the installation. You don't have to recompile the plugins all the time. In most cases I found my plugins should only be recompiled when vdr version changed (then all plugins should be recompiled on a Gentoo machine) or when the plugin's own dependencies has changed. e.g. vdr-xineliboutput is dependent on xine-lib. If xine-lib updated then it would make sense to recompile vdr-xineliboutput again. This is quite manageable on a Gentoo system, I can't speak for other distributions, I can only imagine the same process would apply. > >> On 17 March 2010 07:59, william wrote: >> I have made some other changes. and also got an update from Rob Davis. >> which added ratings and credits >> >> see: http://cobradevil.org/downloads/xmltv2vdr-1.0.9.tar.gz > > Thanks for the pointer. However, the vdr pages do not point to it and this > was my point. > > -- eric Unfortunately it was only on the mailing system... I Hope Klaus will approve it and update his ftp. Works for me :) ___ 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 14.12.2010 16:21, Theunis Potgieter wrote: e.g. vdr-xineliboutput is dependent on xine-lib. If xine-lib updated then it would make sense to recompile vdr-xineliboutput again. Off Topic: vdr-xineliboutput- is currently broken. ___ 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" 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
Al 13/12/10 11:34, En/na Steffen Barszus ha escrit: 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. I'd say that the performance would be better. Right now I have a recording going on. If I press the "up" channel past the last channel on the same transponder, vdr is unresponsive for ~30 seconds. I guess that sqlite, with a well formulated query and the right indexes, would take a fraction of a second to realize that there are no more channels in the same transponder. Bye. -- Luca ___ 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
Am 14.12.2010 20:20, schrieb Steffen Barszus: > 1.) Klaus doesnt like it, also does not like to make it possible to do > it in a plugin. 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. > 2.) Some have a deep hate against any SQL solution. hehe... well not hate, but for all I did with sql by now, it always was a bit clumsy, and needed more extra coding than I would have liked. Once I've even wrote a mini high speed in-between database buffer, as no networked sql database would guarantee reaction times of fractions of mili-seconds, as I needed. Cheers, Udo ___ 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
Al 14/12/10 21:20, En/na Luca Olivetti ha escrit: Al 13/12/10 11:34, En/na Steffen Barszus ha escrit: 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. I'd say that the performance would be better. Right now I have a recording going on. If I press the "up" channel past the last channel on the same transponder, vdr is unresponsive for ~30 seconds. I guess that sqlite, with a well formulated query and the right indexes, would take a fraction of a second to realize that there are no more channels in the same transponder. Instead of speculating I actually tried. I created a test database with the contents of my channels.conf (only containing the number, name, frequency, source, symbol rate and the vpid, I don't think adding all the fields would change the result considerably). With no indexes, the time to get the result to the following query (which is meant to find the next channel in the same transponder) is too short to measure: select * from channels where nr>13 and freq=10992 and params='VC23M2O0S0' and source='S13.0E' and sr=27500 and vpid>0 order by nr limit 1; (note that the machine was running vdr while performing the query). Bye -- Luca ___ 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
Am 14.12.2010 21:20, schrieb Luca Olivetti: > Right now I have a recording going on. If I press the "up" channel past > the last channel on the same transponder, vdr is unresponsive for ~30 > seconds. > I guess that sqlite, with a well formulated query and the right indexes, > would take a fraction of a second to realize that there are no more > channels in the same transponder. Actually, what VDR here does is to tune to each and every channel in your channels.conf after the current, until there's a channel that successfully tunes. Doing an additional sql query for each and every channel in your channels.conf wouldn't improve that, I guess. Two things make this a slow thing: First, the channel list is a linked list, and if you switch from 1000 to 1001, VDR runs through the list starting at 1 until 1001. If 1001 doesn't tune, VDR runs again from 1 to 1002. A C++ map would speed things up a lot, a persistent channel iterator even more. The second thing is the tuning. "Get next channel on this transponder" sounds simple, but actually deciding whether a channel is tuneable involves 17 different rules that get checked against each device, plus probing the CAM whether the channel can be decoded by the CAM. I think that part is even slower than the whole channel list. But after all, there are more important things that need work, than speeding up such special cases. Cheers, Udo ___ 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
Am 14.12.2010 21:56, schrieb Luca Olivetti: > Instead of speculating I actually tried. > I created a test database with the contents of my channels.conf (only > containing the number, name, frequency, source, symbol rate and the > vpid, I don't think adding all the fields would change the result > considerably). > > With no indexes, the time to get the result to the following query > (which is meant to find the next channel in the same transponder) is too > short to measure: > > select * from channels where nr>13 and freq=10992 and > params='VC23M2O0S0' and source='S13.0E' and sr=27500 and vpid>0 order by > nr limit 1; You didn't do a join of the channel list with the list of devices (on tuned transponder, or on not tuned device, or - join with all connected streams of that device - all streams have lower priority than live priority), and a join with all CAM on whether the CAM works with the device, and a join with all CAM slots of all CAMs that can work with device on whether the CAM slot is free or CAM slot priority is lower than live priority. (thats still simplified.) SCNR, Udo ___ 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, Dec 14, 2010 at 12:56 PM, Luca Olivetti wrote: > Instead of speculating I actually tried. > I created a test database with the contents of my channels.conf (only > containing the number, name, frequency, source, symbol rate and the vpid, I > don't think adding all the fields would change the result considerably). Why would you do a test and intentionally discard necessary data fields? If you're not going to run tests using _all_ the actual data, don't bother. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
