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.
I only start investing my time if it has an chance to be included into the VDR. Any comments welcome.
Best regards,
Jochen
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 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.
Klaus
Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
What would that be necessary for?
My previous platform had selectable EPG scans. When I first got into touch with VDR, I asked myself, how I was supposed to restrict searchtimers to interesting channels.
In its default behaviour VDR will add transponders and channels to the channels.conf, as a result these will be searched and probably result in a match and a timer entry, even for uninteresting or undecodable channels.
There are some workarounds for that, which to my taste are not too user friendly:
a) restrict channels.conf to the interesting ones and have VDR not ass transponders and channels [thats what I do].
b) specify a channel range for each of your new search timers (you have to template that to not forget about it).
c) there seems to be a NOEPG patch around to accomplish that.
d) there is a plugin NOEPGMENU around.
I consider the selection of Scan on/off a useful feature.
Best regards
I don't see the advantage of implementing this directly into the VDR. The parameter must be maintained by the user, so it should be an additional configuration file which is independend from the channels.conf, as this file is and should only used for channel information. NOEPG and NOEPGMENU do this job already. If it is not user friendly, it may deserves some improvements.
On 6 December 2010 15:16, Denis Loh denis.loh@googlemail.com wrote:
I don't see the advantage of implementing this directly into the VDR. The parameter must be maintained by the user, so it should be an additional configuration file which is independend from the channels.conf, as this file is and should only used for channel information. NOEPG and NOEPGMENU do this job already. If it is not user friendly, it may deserves some improvements.
iirc noepg still requires a patch
Hi,
I don't see the advantage of implementing this directly into the VDR.
I do and would love to see this feature.
My cable TV provider offers several regional variations of the same TV channel (*). They will show the same shows most of the time and differ only for a regional broadcast once or twice a day.
Using epgsearch, I will get the same movie several times on these channels, with WDR being the worst example.
However, I do not want to remove the variations from my channel list, since there are (rare) occasions when I do want to record a regional broadcast.
Regards,
Hanno
(*) here are just some of them:
NDR Fernsehen Hamburg NDR Fernsehen Mecklenburg-Vorpommern NDR Fernsehen Niedersachsen NDR Fernsehen Schleswig-Holstein
MDR Sachsen MDR Sachsen-Anhalt MDR Thüringen
WDR Aachen WDR Bielefeld WDR Bonn WDR Dortmund WDR Duisburg WDR Düsseldorf WDR Essen WDR Köln WDR Münster WDR Siegen WDR Wuppertal
Am 06.12.2010 13:38, schrieb Mario Schulz:
My previous platform had selectable EPG scans. When I first got into touch with VDR, I asked myself, how I was supposed to restrict searchtimers to interesting channels.
So you want to cut off EPG data for these channels just because epgsearch should ignore them?
EPG is more than an epgsearch database, the better place to blacklist channels would be epgsearch itself imho.
(Does epgsearch have a global blacklist? I lost track on what epgsearch has and what not a long time ago.)
Generally, however, there are a lot of similar needs to influence how VDR does its several automatic scans. Maybe it's time for a generic plugin interface that allows to filter incoming EPG data, channel scan data, transponder data and so on, that allows to do some modifications on-the-fly. This would also allow to fix broken transponders by use of a plugin instead of adding workarounds to VDR.
Cheers,
Udo
Am 06.12.2010 21:30, schrieb Udo Richter:
Generally, however, there are a lot of similar needs to influence how VDR does its several automatic scans. Maybe it's time for a generic plugin interface that allows to filter incoming EPG data, channel scan data, transponder data and so on, that allows to do some modifications on-the-fly. This would also allow to fix broken transponders by use of a plugin instead of adding workarounds to VDR.
I like big solutions which will never be realized. VDR is *full* of them! Such as "sortable menus" realized as MAINMENUHOOKS-patch, but considered as evildoing, such as the NOEPG-patch, such as... , such as... ;)
Regards
Jochen
2010/12/5 Klaus Schmidinger Klaus.Schmidinger@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.
Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
On 05.12.2010 23:01, Jochen Dolze wrote:
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?
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.
The channels.conf file shall contain only data that can be gathered from the transponder.
You write "shall", not "must" ;)
Regards,
Jochen
On 08.12.2010 20:25, Jochen Dolze wrote:
Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
On 05.12.2010 23:01, Jochen Dolze wrote:
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?
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.
Klaus
On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger Klaus.Schmidinger@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
On 09.12.2010 07:59, Steffen Barszus wrote:
On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger Klaus.Schmidinger@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?
Klaus
On Sun, 12 Dec 2010 16:19:00 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 09.12.2010 07:59, Steffen Barszus wrote:
On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger Klaus.Schmidinger@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.
On Sun, Dec 12, 2010 at 9:21 AM, Steffen Barszus steffenbpunkt@googlemail.com 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).
Am Sonntag, den 12.12.2010, 09:33 -0800 schrieb VDR User:
On Sun, Dec 12, 2010 at 9:21 AM, Steffen Barszus steffenbpunkt@googlemail.com 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.
Thanks,
Paul
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepanter@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.
On 12/12/2010 19:24, VDR User wrote:
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepanter@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.
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...
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.
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.
-- eric
On Sun, 12 Dec 2010 19:46:32 +0100 Eric Valette eric.valette@free.fr wrote:
On 12/12/2010 19:24, VDR User wrote:
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepanter@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 :)
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.
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...
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
On 12 December 2010 23:50, Eric Valette eric.valette@free.fr 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 kc@cobradevil.org 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
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, williamkc@cobradevil.org wrote: I have made some other changes. and also got an update from Rob Davis. which added ratings and credits
Thanks for the pointer. However, the vdr pages do not point to it and this was my point.
-- eric
On 14 December 2010 10:49, Eric Valette Eric.Valette@free.fr wrote:
On 17 March 2010 07:59, williamkc@cobradevil.org wrote: I have made some other changes. and also got an update from Rob Davis. which added ratings and credits
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'
On 14.12.2010 12:18, Dominic Evans wrote:
On 14 December 2010 10:49, Eric Valette Eric.Valette@free.fr wrote:
On 17 March 2010 07:59, williamkc@cobradevil.org wrote: I have made some other changes. and also got an update from Rob Davis. which added ratings and credits
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.
I'm afraid I can't find any such request in my mailbox. I've now uploaded the file to ftp://ftp.tvdr.de/vdr/Tools.
Klaus
On 14 December 2010 12:49, Eric Valette Eric.Valette@free.fr 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, williamkc@cobradevil.org wrote: I have made some other changes. and also got an update from Rob Davis. which added ratings and credits
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 :)
On 12.12.2010 19:46, Eric Valette wrote:
On 12/12/2010 19:24, VDR User wrote:
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepanter@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.
Have you ever considered complaining to your broadcasters about this? Here in Germany even DVB-T has an extensive EPG.
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, ...).
I always find it amusing how people consider the GUI so important. Come on! It's a *video recorder* for cryin' out loud! It's main purpose is to record and replay tv broadcasts. The menus are tools that allow the user to program timers, select channels and replay recordings. If the GUI is more important to you than the actual functionality, go ahead and install some of the nice skins floating around, or use something completely different as the user interface. To me, the menu system is nothing more than a means of making VDR do what I want it to do - and that's recording and replaying actual broadcasts, rather than showing me some pretty eye candy.
Klaus
On Sun, Dec 12, 2010 at 2:44 PM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
I always find it amusing how people consider the GUI so important. Come on! It's a *video recorder* for cryin' out loud! It's main purpose is to record and replay tv broadcasts. The menus are tools that allow the user to program timers, select channels and replay recordings. If the GUI is more important to you than the actual functionality, go ahead and install some of the nice skins floating around, or use something completely different as the user interface. To me, the menu system is nothing more than a means of making VDR do what I want it to do - and that's recording and replaying actual broadcasts, rather than showing me some pretty eye candy.
I think you underestimate the amount of time people spend in the menus, whether its searching through tv listings, summaries, recordings, lists of photos/music, etc. There are 4 VDR users in my household and I can say that each of us spend considerable time in the osd doing various things. I don't believe eye candy should be the most important thing but I don't disregard nice osd's as pointless either since they _do_ enhance the user experience. With high resolution HDTV's being common place these days, it's a pretty small leap that users would love to be able to scroll through their channel listings with say high resolution logos for each next to their respective channel numbers. It's true there are skin replacements for the current VDR osd. But, these are merely skins. They aren't full osd overhauls that add any real new possibilities.
As an analogy, some people are perfectly fine with a car that doesn't have things such as power windows/seats, air conditioning, nice woodgrain trim, leather seats, etc. It serves no other purpose then to get that person from point A to point B. However, plenty of other people prefer something more luxurious while they spend time in their car -- and there's nothing wrong with that. VDR's experience from a user perspective isn't simply watching live tv or recordings with nothing in between. The fact that people have expressed their interest on this subject in the past proves the point.
On 12/12/2010 23:44, Klaus Schmidinger wrote:
I always find it amusing how people consider the GUI so important. Come on! It's a *video recorder* for cryin' out loud! It's main purpose is to record and replay tv broadcasts.
I know its the main purpose but do not forget that in order to record, you need to correctly tune the adapter. So its also a DVB tuner. Once tuned, you can direct the stream on disk but also elsewhere. That's the primary purpose of the streamdev extension.
I rarly see VDR used standalone...
--eric
On 13/12/2010 08:21, Eric Valette wrote:
On 12/12/2010 23:44, Klaus Schmidinger wrote:
I always find it amusing how people consider the GUI so important. Come on! It's a *video recorder* for cryin' out loud! It's main purpose is to record and replay tv broadcasts.
I know its the main purpose but do not forget that in order to record, you need to correctly tune the adapter. So its also a DVB tuner. Once tuned, you can direct the stream on disk but also elsewhere. That's the primary purpose of the streamdev extension.
I rarly see VDR used standalone...
Now that the coffee has done its desired effect on my brain, I think this discussion deserves a bit more object oriented style high level analysis.
What is recording? for me its TUNING the adapter, AT A GIVEN TIME, and REDIRECTING the adapter stream to a media..
Regarding TUNING: The initial generation of the channel.conf file is not part of VDR itself. VDR helps reanalysing the channel.conf by tuning and analysing the stream to find the apid, vpid, teletex, ... Why is the initial tuning handled externaly and then finalysed? Its a primary function right? I do not care if w-scan is extended for correct HDTV/S2 generation of if its incorporated. But VDR is not self sufficient for that function.
AT A GIVEN TIME: then comes the questions of 1) how do you know there is something you want to record 2) when it is? 3) how simple is it to do?
For people familiar with paid TV dedicated devices, most of the time it relies on extended EPG database and search function in it. Again this is not part of VDR itself as EPG handling and search is external. Plus in france, the actual EPG handling is not sufficient. And broadcaster is the state for some channels so I can try to complain but will probably not obtain much...
REDIRECTING the stream: To a file. OK. Its part of VDR. I would have liked to be able to record to something else than mpeg2ts because of the audio/video synchronisation, lack of metadata, ... Both problems are being addressed by the naming of the record location, the info file and the recording of the I frame location. Using a .mkv would have been more efficient especially for playback outside VDR... Then of course we also may want to redirect the stream on a socket for network streaming using a dedicated protocol. This part is again not part of VDR itself but comes with streamdev, vnsi, but with the extra cost of duplicating demuxer code.
Then of course, you should think on how you expose the core functionality outside of VDR.
So I think the analysis og basic function in VDR do deserve a bit more attention.
And do not misunderstand me: I'm glad VDR exist but I spend really to much time trying to incorporate it in a decent looking HTPC environment. And Klaus, thanks for your support I would not have managed without it. I'm not entirely satisfyied by the result and the main missing part are: 1) decent looking GUI, 2) EPG
I started looking at tvheadend because:
1) channels.conf generation is incorporated somehow (in a way that fails for me ;-)) But using w-scan to find the transponder you can manage it, 2) It has support for xmltv (not yet tried) 3) It has been designed with a video streaming perspective 4) It also has an build-in live equivalent and recording 5) XBMC has native streaming protocol for it not yet for VDR,
Unfortunately, it still suffers for some bugs for HDTV support. Life is always complicated.
--eric
On Sun, 12 Dec 2010 10:24:31 -0800 VDR User user.vdr@gmail.com wrote:
On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepanter@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 ;)
On Sun, Dec 12, 2010 at 11:14 AM, Steffen Barszus steffenbpunkt@googlemail.com wrote:
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 wouldn't be so quick to disregard user opinion. I think it's important to consider what people think who are using sql in a similar way. Do you honestly believe their first-hand experience in this area is meaningless, and that all the complaints about it with virtually nobody suggesting its a great idea is mere worthless chatter? There's a reason sql is unpopular. It's unfortunate you think that has no value and should be disregarded. It seems you think anything or any opinion that doesn't support the idea simply 'doesn't add anything'. I know a whole lot of users who will disagree with you on that.
There are also other options that could be explored as well - and should be if there's to be any changes made.
(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 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.
--eric
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.
--eric
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
On Mon, 13 Dec 2010 17:58:50 +0100 Denis Loh denis.loh@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.
On 12.12.2010 18:21, Steffen Barszus wrote:
On Sun, 12 Dec 2010 16:19:00 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 09.12.2010 07:59, Steffen Barszus wrote:
On Wed, 08 Dec 2010 23:22:05 +0100 Klaus Schmidinger Klaus.Schmidinger@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.
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).
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
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.
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.
Klaus
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?
On Mon, 13 Dec 2010 00:00:27 +0000 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.
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?
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.
(not that the VDR internal structures are that impressive fast, though. I wonder how much it would gain by using C++ map and similar.)
Cheers,
Udo
On Mon, 13 Dec 2010 22:19:45 +0100 Udo Richter udo_richter@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.
On 13/12/10 21:19, Udo Richter 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?
With sqlite you usually compile your SQL statements in advance and bind different values to a compiled statement's parameters as needed. It can also operate entirely in memory instead of with a file and there are functions to quickly transfer databases between memory and disc. There's no client-server overhead either, although that has the disadvantage that it would be more difficult for another application to use the database while VDR is running [1]. There's no problem with the data being stored in a non-text format because of the very good sqlitebrowser.
[1] Maybe there could be an SVDRP command to execute arbitrary SQL statements, but there'd need to be some agreed way to format the return values for queries.
Am Mon, 13 Dec 2010 22:19:45 +0100 schrieb Udo Richter udo_richter@gmx.de:
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.
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.
Gerald
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.
On Mon, Dec 13, 2010 at 2:53 PM, Helmut Auer vdr@helmutauer.de wrote:
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.
I think epg.data is written at certain intervals as well (every 15mins or so?), but I could be wrong.
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
On Tue, 14 Dec 2010 10:31:03 +0100 (CET) "Gerald Dachs" vdr@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 ... :(
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
On Tue, 14 Dec 2010 21:46:52 +0100 Udo Richter udo_richter@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.
Steffen Barszus wrote:
well the point was to make it simpler, improving something. This goal would be missed by that.
"simple" is a matter of definition. I think the VDR built-in handlers of configuration files are very simple with the big benefit of being plain text.
Yours
Manuel
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.
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
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
On Tue, Dec 14, 2010 at 12:56 PM, Luca Olivetti luca@ventoso.org 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.
Al 15/12/10 00:19, En/na VDR User ha escrit:
On Tue, Dec 14, 2010 at 12:56 PM, Luca Olivettiluca@ventoso.org 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.
Because, without indexes, sqlite will do a linear scan, so, e.g., doubling the data per record, will roughly double the time, and the double of "imperceptible" is "too little to notice". But that anyway would be offset by using indexes and optimizing the data types (e.g. in my query I used strings for parameters and source, and those are very inefficient, intentionally so, just to show that sqlite wouldn't be a bottleneck).
Bye
On Wed, Dec 15, 2010 at 9:21 AM, Luca Olivetti luca@ventoso.org 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.
Because, without indexes, sqlite will do a linear scan, so, e.g., doubling the data per record, will roughly double the time, and the double of "imperceptible" is "too little to notice". But that anyway would be offset by using indexes and optimizing the data types (e.g. in my query I used strings for parameters and source, and those are very inefficient, intentionally so, just to show that sqlite wouldn't be a bottleneck).
Then you create indexes, not discard a big portion of necessary data.
I don't understand what would be easy in using SQL. Since the channels.conf-code is already there, and pretty stable, then obviously rewriting that to SQL is not "easy", but instead additional work. Justifying additional work needs some reason.
I think adding dependencies to outside packages is a burden that should be avoided. There are already many things I need to install separately in order the vdr box to work; kernel, graphics drivers, and xine-lib. Luckily, lirc is now already part of the kernel, and DVB drivers, too; much less hassle than before. This is the right direction to go - not adding more moving parts that need to be installed (with compatible versions).
yours, Jouni
Al 15/12/10 20:57, En/na Jouni Karvo ha escrit:
I don't understand what would be easy in using SQL. Since the channels.conf-code is already there, and pretty stable, then obviously rewriting that to SQL is not "easy", but instead additional work. Justifying additional work needs some reason.
Well, I don't actually care either way. Using sql has advantages and disadvantages, using channels.conf has another set of advantages and disadvantages. I just don't like the spreading of FUD.
I think adding dependencies to outside packages is a burden that should be avoided.
I assure you that sqlite wouldn't be a burden. It's no more of an external dependency than, say, libc.
Bye
On Wednesday 15 December 2010, Jouni Karvo wrote:
I think adding dependencies to outside packages is a burden that should be avoided. There are already many things I need to install separately in order the vdr box to work; kernel, graphics drivers, and xine-lib. Luckily, lirc is now already part of the kernel, and DVB drivers, too; much less hassle than before. This is the right direction to go - not adding more moving parts that need to be installed (with compatible versions).
I'm not saying anything about the epg data as plain text vs sqlite thing, but would like to note that things are not always that black and white as the above seems to say. In my opinion it does not make sense to reimplement everything that's required just in order to avoid dependencies (but other valid reasons for not using something that's already there might of course exist).
On 12/15/2010 10:49 PM, Ville Skyttä wrote:
On Wednesday 15 December 2010, Jouni Karvo wrote:
I think adding dependencies to outside packages is a burden that should be avoided. There are already many things I need to install separately in order the vdr box to work; kernel, graphics drivers, and xine-lib. Luckily, lirc is now already part of the kernel, and DVB drivers, too; much less hassle than before. This is the right direction to go - not adding more moving parts that need to be installed (with compatible versions).
I'm not saying anything about the epg data as plain text vs sqlite thing, but would like to note that things are not always that black and white as the above seems to say. In my opinion it does not make sense to reimplement everything that's required just in order to avoid dependencies (but other valid reasons for not using something that's already there might of course exist).
And it's not only to avoid unnecessary wheel inventing but also going towards more generic solution of the software itself. If I'm not mistaking sqlite would actually help also in multi-instance ("server" solution) vdr implementation when each instance would be reading/writing from/to same DB but also external tools to read/write epg data way more faster than via vdr.
But this depate can go on forever back and forth - probably leading to no changes what so ever. Klaus have already decided few posts ago to keep the text file based solution. Same goes for standalone-server wishes (vdr will not change to server-client system). And same for few other features.
That said and with no disrespect to the author of vdr in my opinion it starts to be a time to fork vdr and redefine its base + few other elements. There are many very talented coders reading this mailing-list (+ many others over different vdr related sites) who are developing plugins and patches - some being very big. Put sources to accessible version control system (almost already existing at place where previously unmaintained plugins where brought alive), set up issue handling system with roadmaps etc. (like Mantis) and of course set up a core team of developers who make decisions what go in and what not. I believe this would also speed up the development of the vdr itself tremendeously due to much greater man power.
Of course things can remain the same but will we ever see natively implemented in vdr: -_proper_ implementation of server-client solution (centralized records, epg etc. without "hacks") -good looking high res OSD -good integration to XBMC or similar -fully redefinable menu system -channel specific configurability (epg...) -native ATSC support -several of the big patches integrated (long list) and configurable -etc.etc.
If I've not read incorrectly what have been written in this mailing-list then the answer is *no*.
Hope to get some active discussion around this and actions as well.
Br, Pasi
Dear Pasi,
it is a great idea to fork a new line and rewrite code to satisfy all requests which been put forward.
Please let me know when you will set a repository and write stable code so that I could give it a try. Please make changes quick so that people who was waiting for this changes had a chance to have better software.
You will be our hero.
NOTE: many demand but few commit time and do it.
Thank you, Andy
On 17/12/10 1:58 PM, Pasi Juppo wrote:
On 12/15/2010 10:49 PM, Ville Skyttä wrote:
On Wednesday 15 December 2010,
Jouni Karvo wrote:
I think adding dependencies to outside packages is a
burden that
should be avoided. There are already many things I need
to install
separately in order the vdr box to work; kernel, graphics
drivers,
and xine-lib. Luckily, lirc is now already part of the
kernel, and
DVB drivers, too; much less hassle than before. This is
the right
direction to go - not adding more moving parts that need
to be
installed (with compatible versions).
I'm not saying anything about the epg data as plain text vs
sqlite
thing, but would like to note that things are not always that
black
and white as the above seems to say. In my opinion it does
not make
sense to reimplement everything that's required just in order
to
avoid dependencies (but other valid reasons for not using
something
that's already there might of course exist).
And it's not only to avoid unnecessary wheel inventing but also going towards more generic solution of the software itself. If I'm not mistaking sqlite would actually help also in multi-instance ("server" solution) vdr implementation when each instance would be reading/writing from/to same DB but also external tools to read/write epg data way more faster than via vdr.
But this depate can go on forever back and forth - probably leading to no changes what so ever. Klaus have already decided few posts ago to keep the text file based solution. Same goes for standalone-server wishes (vdr will not change to server-client system). And same for few other features.
That said and with no disrespect to the author of vdr in my opinion it starts to be a time to fork vdr and redefine its base + few other elements. There are many very talented coders reading this mailing-list (+ many others over different vdr related sites) who are developing plugins and patches - some being very big. Put sources to accessible version control system (almost already existing at place where previously unmaintained plugins where brought alive), set up issue handling system with roadmaps etc. (like Mantis) and of course set up a core team of developers who make decisions what go in and what not. I believe this would also speed up the development of the vdr itself tremendeously due to much greater man power.
Of course things can remain the same but will we ever see natively implemented in vdr: -_proper_ implementation of server-client solution (centralized records, epg etc. without "hacks") -good looking high res OSD -good integration to XBMC or similar -fully redefinable menu system -channel specific configurability (epg...) -native ATSC support -several of the big patches integrated (long list) and configurable -etc.etc.
If I've not read incorrectly what have been written in this mailing-list then the answer is *no*.
Hope to get some active discussion around this and actions as well.
Br, Pasi
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 17.12.2010 22:58, schrieb Pasi Juppo:
That said and with no disrespect to the author of vdr in my opinion it starts to be a time to fork vdr and redefine its base + few other elements.
Of course things can remain the same but will we ever see natively implemented in vdr: -_proper_ implementation of server-client solution (centralized records, epg etc. without "hacks") -good looking high res OSD -good integration to XBMC or similar -fully redefinable menu system -channel specific configurability (epg...) -native ATSC support -several of the big patches integrated (long list) and configurable -etc.etc.
If you want to go that way, you should start from scratch, as your feature list requires rewrite of most of VDR anyway. Client-server multihead for example requires to dump the whole OSD, menu, plugin and skin system.
And don't expect this to be easy: Even if you have several good coders with lots of spare time, things will take months to years to finish.
Good luck, I'll stay on VDR until then.
Cheers,
Udo
On Sat, Dec 18, 2010 at 5:33 AM, Udo Richter udo_richter@gmx.de wrote:
Am 17.12.2010 22:58, schrieb Pasi Juppo:
That said and with no disrespect to the author of vdr in my opinion it starts to be a time to fork vdr and redefine its base + few other elements.
Of course things can remain the same but will we ever see natively implemented in vdr: -_proper_ implementation of server-client solution (centralized records, epg etc. without "hacks") -good looking high res OSD -good integration to XBMC or similar -fully redefinable menu system -channel specific configurability (epg...) -native ATSC support -several of the big patches integrated (long list) and configurable -etc.etc.
If you want to go that way, you should start from scratch, as your feature list requires rewrite of most of VDR anyway. Client-server multihead for example requires to dump the whole OSD, menu, plugin and skin system.
And don't expect this to be easy: Even if you have several good coders with lots of spare time, things will take months to years to finish.
You actually make an important point. VDR was never designed with server/client in mind. I'm not sure Klaus realized how many people would want to use it in that scenario, or that he envisioned htpc's becoming such a central piece of peoples living rooms, providing media/entertainment. Peoples needs and wants have simply outgrown what VDR was ever intended to do. This isn't to say there isn't room for improvement and that VDR can't mature from it's original design and intention. I also wouldn't completely disregard Klaus's willingness to take user opinion into consideration. Remember, it wasn't long ago that he wasn't thrilled at the thought of HDTV and mpeg-ts. But, there was clearly a big need/want for these things from users and he eventually added these things. Then you have the addition of ATSC support, which I'm almost positive was pretty low on the priority list. I know many NA users that have felt abandoned and left out in the cold for years, yet ATSC is now there.
This should give us hope that we might some of the things we really want, even if Klaus doesn't care much about it. Correct me if I'm wrong but didn't he actually say at one point he _would_ revamp the OSD system to something far more flexible and not so restricted and simplistic?
Some things have no hope of ever making it into VDR, a couple things possibly might (though who knows when), and the stuff Klaus feels are important obviously get the most attention. As you know Klaus doesn't share the TODO list but I can't recall too many things he said flat out he won't consider.
In the mean time, from what I hear Windows has come a long way when it comes to this stuff. If you want a good stable option, that may be the route to go until VDR catches up with the times. If anyone feels compelled to turn that statement into a Windows vs. Linux debate, please fork a new thread! And speaking of forks, the subject of VDR being forked to allow a lot more development is not new. IIRC, Klaus said that is anyone does that, he will discontinue work on VDR altogether. If that's true be careful what you wish for!
Lastly, my apologies if I've remembered anything incorrectly. I might be typing but I'm far from being total awake yet. :)
Hello,
You actually make an important point. VDR was never designed with server/client in mind.
But there are plugins out there, that can add exactly what you need. One of them is "streamdev", which does a very good job.
Not anyone wants a client/server setup, so why should those people, not needing a networked setup, be forced to have all this stuff in their system, probably making things much slower.
Another point is, that the more code you add to the core codebase, the more time is needed to keep things running and fix bugs...
Correct me if I'm wrong but didn't he actually say at one point he _would_ revamp the OSD system to something far more flexible and not so restricted and simplistic?
I like the OSD the way it is. It's one reason why I prefer VDR to other solutions. IMHO only a few changes are really needed in the OSD: Optional usage of true color for theme authors and a customizable main menu (Plain-Text configuration based on the class already used for commands.conf).
If I follow this discussion, then some people seem to not want to use VDR at all. If you don't like VDR, then maybe you want to have a look at other solutions. Maybe XBMC with its "tv-headend" or MythTV and if you want to use Windows, then please do so.
To get back to topic. IIRC Klaus suggested a fix for the bug discussed in this thread, before it got off topic. Did someone already start to create a fix based on Klaus's suggestion?
Yours
Manuel
On Sun, Dec 19, 2010 at 2:43 AM, Manuel Reimer Manuel.Reimer@gmx.de wrote:
You actually make an important point. VDR was never designed with server/client in mind.
But there are plugins out there, that can add exactly what you need. One of them is "streamdev", which does a very good job.
I disagree about streamdev doing a 'very good job'. That certainly wasn't my experience when I tried it, though that was some time ago. And even if you manage to get streamdev working, you still have other issues which should be non-existent in a design where server/client has been considered.
Not anyone wants a client/server setup, so why should those people, not needing a networked setup, be forced to have all this stuff in their system, probably making things much slower.
There's not a single good reason a 'single instance' user would feel any negative impact of VDR where it to contain real server/client support.
Another point is, that the more code you add to the core codebase, the more time is needed to keep things running and fix bugs...
I hope you're not suggesting that maintaining server/client code is somehow tedious and time-consuming, especially in Linux.
Correct me if I'm wrong but didn't he actually say at one point he _would_ revamp the OSD system to something far more flexible and not so restricted and simplistic?
I like the OSD the way it is. It's one reason why I prefer VDR to other solutions. IMHO only a few changes are really needed in the OSD: Optional usage of true color for theme authors and a customizable main menu (Plain-Text configuration based on the class already used for commands.conf).
So you don't actually like the OSD the way it is. In your own words in the above quote you admit to wanting true color & customizable menus/themes - two of the biggest user wishes in terms of OSD. You see the irony right?
If I follow this discussion, then some people seem to not want to use VDR at all. If you don't like VDR, then maybe you want to have a look at other solutions. Maybe XBMC with its "tv-headend" or MythTV and if you want to use Windows, then please do so.
Don't mistake people wanting VDR to be more capable and provide more user experience for them not liking or wanting to use VDR. If that were the case they probably wouldn't be on the VDR mailing list talking about ways to improve it. Also, I haven't noticed a single comment from anyone expressing such a dislike and there's no reason for you to take offense at the fact people want these things for VDR. That we're even having this discussion contradicts your theory in the first place. A lot of people love VDR, myself being one of them, and it's not a crime to see past where it was originally intended to be when it was designed _over 10 years ago_.
On 18/12/2010 14:33, Udo Richter wrote:
Am 17.12.2010 22:58, schrieb Pasi Juppo:
That said and with no disrespect to the author of vdr in my opinion it starts to be a time to fork vdr and redefine its base + few other elements.
Of course things can remain the same but will we ever see natively implemented in vdr: -_proper_ implementation of server-client solution (centralized records, epg etc. without "hacks") -good looking high res OSD -good integration to XBMC or similar -fully redefinable menu system -channel specific configurability (epg...) -native ATSC support -several of the big patches integrated (long list) and configurable -etc.etc.
If you want to go that way, you should start from scratch, as your feature list requires rewrite of most of VDR anyway. Client-server multihead for example requires to dump the whole OSD, menu, plugin and skin system.
And don't expect this to be easy: Even if you have several good coders with lots of spare time, things will take months to years to finish.
Good luck, I'll stay on VDR until then.
Instead of discouraging people, even if you are convinced that nobody can create something superior than what exist, you should encourage them.
So do I.
-- eric
Al 15/12/10 20:35, En/na VDR User ha escrit:
On Wed, Dec 15, 2010 at 9:21 AM, Luca Olivettiluca@ventoso.org 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.
Because, without indexes, sqlite will do a linear scan, so, e.g., doubling the data per record, will roughly double the time, and the double of "imperceptible" is "too little to notice". But that anyway would be offset by using indexes and optimizing the data types (e.g. in my query I used strings for parameters and source, and those are very inefficient, intentionally so, just to show that sqlite wouldn't be a bottleneck).
Then you create indexes, not discard a big portion of necessary data.
Ok I created an index
create index transp on channels (freq, params, source, sr);
Now the reply to the query is immediate. Since I don't have time to create a proper table, I added a dummy column in order that each row has at least three times the amount of "necessary data". The reply is still immediate.
Bye
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
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.
I agree, I have one vdr-server + 3 active xineliboutput clients. Nowadays each of the clients are sharing the same channel list because I have felt it to be too hacky to put multiple vdr instances to run on that vdr-server.
It would really be nice to have some kind of "server" interface to vdr so that one vdr instance could really support multiple clients with different dvb tuners in case there are some of them still unused.
Mika
Hi!
Look at streamdev plugin (plus remotetimers), this will solve your problem.
Regards
Marco
Am 03.01.2011 23:29, schrieb Mika Laitio:
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.
I agree, I have one vdr-server + 3 active xineliboutput clients. Nowadays each of the clients are sharing the same channel list because I have felt it to be too hacky to put multiple vdr instances to run on that vdr-server.
It would really be nice to have some kind of "server" interface to vdr so that one vdr instance could really support multiple clients with different dvb tuners in case there are some of them still unused.
Mika
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Sun, 12 Dec 2010 23:33:13 +0100 Klaus Schmidinger Klaus.Schmidinger@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.
On 12/13/10 11:49, Steffen Barszus wrote:
On Sun, 12 Dec 2010 23:33:13 +0100 Klaus Schmidinger Klaus.Schmidinger@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.
Klaus
-----Original Message-----
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.
Klaus
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Thanks Klaus, couldn't agree more. Back in the dark ages I chose VDR over Myth more or less because of that. /Magnus H
On 12/13/2010 01:44 PM, Klaus Schmidinger wrote:
On 12/13/10 13:40, Eric Valette wrote:
On 12/13/2010 12:14 PM, Klaus Schmidinger wrote:
Of course, but they are *simple* databases ;-)
xmltv format is ascii also ;-)
So?
so you could use another source to feed your ascii database.
-- eric
On Mon, 13 Dec 2010 12:14:48 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 12/13/10 11:49, Steffen Barszus wrote:
On Sun, 12 Dec 2010 23:33:13 +0100 Klaus Schmidinger Klaus.Schmidinger@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 ...
En/na Klaus Schmidinger ha escrit:
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.
text files, yes, plain readable, no (with all special symbols, special cases, etc.).
Bye
Am 12.12.2010 16:19, schrieb Klaus Schmidinger:
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?
There are three usecases for adding EPG-Data:
1. Using EIT-EPG as it is 2. Adding Information to existing EIT-EPG and setting table id to 0 to prevent overwrites of the new Information (often only Shorttext) 3. Adding complete new EPG from other sources and prevent EIT-EPG to fill tables with noepg-patch
With your proposed solution, i'm not able to add informations to existing events, cause i cannot tag the event with table id 0 to prevent overwrites, instead tagging with table id 0 will stop adding EIT-EPG.
It would be nice, to have a solution where all three usecases are usable. Today we only have two, with the ugly noepg-patch all of them.
Or, we just set te tableid to -1 (if thats possible) to indicate "stop adding EIT-EPG", 0 "stop overwrite event", >0 "do what you want"
Regards
Jochen
On 27.12.2010 13:07, Jochen Dolze wrote:
Am 12.12.2010 16:19, schrieb Klaus Schmidinger:
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?
There are three usecases for adding EPG-Data:
- Using EIT-EPG as it is
- Adding Information to existing EIT-EPG and setting table id to 0 to
prevent overwrites of the new Information (often only Shorttext) 3. Adding complete new EPG from other sources and prevent EIT-EPG to fill tables with noepg-patch
With your proposed solution, i'm not able to add informations to existing events, cause i cannot tag the event with table id 0 to prevent overwrites, instead tagging with table id 0 will stop adding EIT-EPG.
It would be nice, to have a solution where all three usecases are usable. Today we only have two, with the ugly noepg-patch all of them.
Or, we just set te tableid to -1 (if thats possible) to indicate "stop adding EIT-EPG", 0 "stop overwrite event", >0 "do what you want"
Well, I guess you'll need to make up your mind about what you actually want. You can either use the EPG as provided by the broadcasters, or use your own EPG data from whatever source that may be. VDR only works as designed if it uses (only) the EPG from the broadcaster, because that's identifiable by event ids and can make use of VPS control. As soon as you stuff in your own data, I suggest you do *everything* with your own data. Having some data from the broadcaster and some from other sources makes things unnecessarily complex, so I don't like that.
So it's either making VDR ignore any EIT EPG data if the first event for a particular channel has a zero table id, or leaving everything as it is right now.
Klaus
-
Andrey Vlassov -
Denis Loh -
Dominic Evans -
Eric Valette -
Eric Valette
-
Gerald Dachs -
Hanno Zulla -
Helmut Auer -
Jochen Dolze -
Jouni Karvo -
Klaus Schmidinger -
Luca Olivetti -
Magnus H -
Manuel Reimer -
Marco Göbenich -
Mario Schulz -
Mika Laitio -
Pasi Juppo -
Paul Menzel -
Pertti Kosunen -
Steffen Barszus -
Theunis Potgieter -
Tony Houghton -
Udo Richter -
VDR User -
Ville Skyttä