Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On Wed, 3 Mar 2010, Timothy D. Lenz wrote: If it's going to be limited to 1 letter, v does seem right for video, i for iptv would be good. I think ATSC uses ether c or t. Not sure. But if I understand what is happening here, might be a good idea to go to a 2 or 3 letter ID right now so things don't have to be patched latter. IPTV will be using 'I' - at least my initial implementation does. Anyway I cannot imagine a situation that there ever will be more input plugins than there are available visible characters (26 [A-Z] + 26 [a-z] + 10 [0-9] + ...). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On 03/04/10 10:30, Rolf Ahrenberg wrote: On Wed, 3 Mar 2010, Timothy D. Lenz wrote: If it's going to be limited to 1 letter, v does seem right for video, i for iptv would be good. I think ATSC uses ether c or t. Not sure. But if I understand what is happening here, might be a good idea to go to a 2 or 3 letter ID right now so things don't have to be patched latter. IPTV will be using 'I' - at least my initial implementation does. Anyway I cannot imagine a situation that there ever will be more input plugins than there are available visible characters (26 [A-Z] + 26 [a-z] + 10 [0-9] + ...). There will only be 'A' to 'Z' - and I also think this should be enough ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
Someone once said they didn't see a need for more then 640k of ram too :) May not need 30+ symbols, but to keep to symbols that somewhat match what they are for would call for reuse of some letters. On 3/4/2010 2:30 AM, Rolf Ahrenberg wrote: On Wed, 3 Mar 2010, Timothy D. Lenz wrote: If it's going to be limited to 1 letter, v does seem right for video, i for iptv would be good. I think ATSC uses ether c or t. Not sure. But if I understand what is happening here, might be a good idea to go to a 2 or 3 letter ID right now so things don't have to be patched latter. IPTV will be using 'I' - at least my initial implementation does. Anyway I cannot imagine a situation that there ever will be more input plugins than there are available visible characters (26 [A-Z] + 26 [a-z] + 10 [0-9] + ...). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On Thu, 4 Mar 2010, Timothy D. Lenz wrote: May not need 30+ symbols, but to keep to symbols that somewhat match what they are for would call for reuse of some letters. Well, even I do prefer I - IPTV, but I don't see no problems using X - IPTV. The description of source params explains perfectly the source in both cases - no matter what the type character is. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
Hi, Am 28.02.2010 16:07, schrieb Klaus Schmidinger: - Plugins can now define new sources. In order to implement this, the following changes were made: + The transponder parameter string is no longer interpreted by cChannel, but rather stored as is and used only by the respective device. That way plugins can use a channel's parameter string to store arbitrary data (see vdr.5). + The new class cSourceParam can be used by plugins to define new sources, and to implement OSD items that will be used in the channel editor for editing the source specific parameters of a channel (see dvbdevice.c for an example of how this is done for the default DVB devices). + Purely numerical values are no longer accepted in the 'source' parameter of a channel. This obsoletes the PLUGINPARAM patch. Is it right, that the sources have to be unique across the different plugins, at least at one installation? Where can I register for an official source-character? Who would document the assigned sources and where? 'C', 'S' and 'T' are used by dvbdevice, 'P' was used by the plugin-param-patch. Since it was used for e.g. iptv and pvrinput, I guess these plugins shall use different ones now, since they have different syntax? On my first thought I considered to take 'A' for 'analog', but since there is something like ATSC (and I know nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one? So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices. What are you thinking? Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch d...@flensrocker.de wrote: On my first thought I considered to take 'A' for 'analog', but since there is something like ATSC (and I know nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one? So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices. ATSC is a set of standards developed by the Advanced Television Systems Committee for digital television transmission. ATSC replaced much of the analog NTSC television system[1] in the United States[2][3] on June 12, 2009 and will replace NTSC by August 31, 2011 in Canada[4] and December 31, 2021 in Mexico. Yes, I think you should take ATSC into consideration unless you want to ignore North America. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On 03/03/10 13:35, VDR User wrote: On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch d...@flensrocker.de wrote: On my first thought I considered to take 'A' for 'analog', but since there is something like ATSC (and I know nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one? So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices. ATSC is a set of standards developed by the Advanced Television Systems Committee for digital television transmission. ATSC replaced much of the analog NTSC television system[1] in the United States[2][3] on June 12, 2009 and will replace NTSC by August 31, 2011 in Canada[4] and December 31, 2021 in Mexico. Yes, I think you should take ATSC into consideration unless you want to ignore North America. ;) Except ATSC is a subset of DVB.. At the moment ATSC is flagged as T, which I think it should be.. For people that don't really know, ATSC comes in two flavours (or flavors), Over the Air, and Clear Qam. Over the air is using a roof top antenna, like DVB-T, then we get Clear Qam, where you plugin the input from your cable company. By law all cable companies must provide clear (ie, non encoded) local channels. However, Comcast in our region has just released a Basic Digital package, which means we get about 60 channels now Clear Qam, including stuff you would have thought would be encoded (and is on Euro Sat). If you don't want to mess with Nagra-3, card readers, and such like, it's the best way to get VDR showing useful programming. Now, if only there was a channel scanner that could write a VDR style channels.conf with ATSC.. Just in case someone is searching archives, the best way to work out what you should have in your area is to look at the silicon dust website (the manufactorer of the the hdhomerun devices. These will show you (by zip) for OTA and Cable.. My zip code is here: http://www.silicondust.com/hdhomerun/lineup_web/US:61103#lineup_1635553 A channel scanner won't always find the info you need for Cable.. I had to manually insert several Vpids (which for my area were one less than the apid) and turn off auto update.. I then had to tell VDR they were type =2.. Maybe I'll do a Comcast-VDR howto sometime.. -- Rob Davis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
Am 03.03.2010 20:35, schrieb VDR User: On Wed, Mar 3, 2010 at 10:47 AM, L. Hanischd...@flensrocker.de wrote: On my first thought I considered to take 'A' for 'analog', but since there is something like ATSC (and I know nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one? So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices. ATSC is a set of standards developed by the Advanced Television Systems Committee for digital television transmission. ATSC replaced much of the analog NTSC television system[1] in the United States[2][3] on June 12, 2009 and will replace NTSC by August 31, 2011 in Canada[4] and December 31, 2021 in Mexico. Yes, I think you should take ATSC into consideration unless you want to ignore North America. ;) That was never my intention... :-) I knew ATSC is an american standard for television, but I do not know with which devices it can be received with linux. Is it part of v4l or of dvb (or somehow both of them)? Are there patches for vdr which exposes a new kind of device or is it an extension of the existing dvbdevice? Anyway I would like to claim the source identifier 'V' for pvrinput. Just for the records... Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On Wed, 03 Mar 2010 15:56:06 -0600 Rob Davis r...@davis-family.info wrote: Except ATSC is a subset of DVB.. At the moment ATSC is flagged as T, which I think it should be.. It isn't just a subset, I think its SI tables have a different structure from DVB. That's probably why it isn't supported natively by VDR. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
If it's going to be limited to 1 letter, v does seem right for video, i for iptv would be good. I think ATSC uses ether c or t. Not sure. But if I understand what is happening here, might be a good idea to go to a 2 or 3 letter ID right now so things don't have to be patched latter. On 3/3/2010 11:47 AM, L. Hanisch wrote: Hi, Am 28.02.2010 16:07, schrieb Klaus Schmidinger: - Plugins can now define new sources. In order to implement this, the following changes were made: + The transponder parameter string is no longer interpreted by cChannel, but rather stored as is and used only by the respective device. That way plugins can use a channel's parameter string to store arbitrary data (see vdr.5). + The new class cSourceParam can be used by plugins to define new sources, and to implement OSD items that will be used in the channel editor for editing the source specific parameters of a channel (see dvbdevice.c for an example of how this is done for the default DVB devices). + Purely numerical values are no longer accepted in the 'source' parameter of a channel. This obsoletes the PLUGINPARAM patch. Is it right, that the sources have to be unique across the different plugins, at least at one installation? Where can I register for an official source-character? Who would document the assigned sources and where? 'C', 'S' and 'T' are used by dvbdevice, 'P' was used by the plugin-param-patch. Since it was used for e.g. iptv and pvrinput, I guess these plugins shall use different ones now, since they have different syntax? On my first thought I considered to take 'A' for 'analog', but since there is something like ATSC (and I know nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one? So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices. What are you thinking? Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
I'm not sure, but I think Korea is going to use ATSC also. On 3/3/2010 12:35 PM, VDR User wrote: On Wed, Mar 3, 2010 at 10:47 AM, L. Hanischd...@flensrocker.de wrote: On my first thought I considered to take 'A' for 'analog', but since there is something like ATSC (and I know nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one? So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices. ATSC is a set of standards developed by the Advanced Television Systems Committee for digital television transmission. ATSC replaced much of the analog NTSC television system[1] in the United States[2][3] on June 12, 2009 and will replace NTSC by August 31, 2011 in Canada[4] and December 31, 2021 in Mexico. Yes, I think you should take ATSC into consideration unless you want to ignore North America. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
There is a plugin for ATSC: http://www.fepg.org/atscepg/ http://dvbn.happysat.org/viewtopic.php?f=17t=36463 It is a patch to vdr to use ATSC and it has a scanner to scan for channels and create a channels.conf. Current HG version also lets you select which tuner is used for channel scanning and select between atsc and cable. I currently am having problems with this version segfaulting when trying to scan, but it seems to be ok for others. Also, the cable scanning part is still in the works. I tried scanning my cable with another program and found some 300+ channels, but with the plugin, while it was able to tune a number of frequancies, only found 5 local channels. On 3/3/2010 2:56 PM, Rob Davis wrote: On 03/03/10 13:35, VDR User wrote: On Wed, Mar 3, 2010 at 10:47 AM, L. Hanischd...@flensrocker.de wrote: On my first thought I considered to take 'A' for 'analog', but since there is something like ATSC (and I know nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one? So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices. ATSC is a set of standards developed by the Advanced Television Systems Committee for digital television transmission. ATSC replaced much of the analog NTSC television system[1] in the United States[2][3] on June 12, 2009 and will replace NTSC by August 31, 2011 in Canada[4] and December 31, 2021 in Mexico. Yes, I think you should take ATSC into consideration unless you want to ignore North America. ;) Except ATSC is a subset of DVB.. At the moment ATSC is flagged as T, which I think it should be.. For people that don't really know, ATSC comes in two flavours (or flavors), Over the Air, and Clear Qam. Over the air is using a roof top antenna, like DVB-T, then we get Clear Qam, where you plugin the input from your cable company. By law all cable companies must provide clear (ie, non encoded) local channels. However, Comcast in our region has just released a Basic Digital package, which means we get about 60 channels now Clear Qam, including stuff you would have thought would be encoded (and is on Euro Sat). If you don't want to mess with Nagra-3, card readers, and such like, it's the best way to get VDR showing useful programming. Now, if only there was a channel scanner that could write a VDR style channels.conf with ATSC.. Just in case someone is searching archives, the best way to work out what you should have in your area is to look at the silicon dust website (the manufactorer of the the hdhomerun devices. These will show you (by zip) for OTA and Cable.. My zip code is here: http://www.silicondust.com/hdhomerun/lineup_web/US:61103#lineup_1635553 A channel scanner won't always find the info you need for Cable.. I had to manually insert several Vpids (which for my area were one less than the apid) and turn off auto update.. I then had to tell VDR they were type =2.. Maybe I'll do a Comcast-VDR howto sometime.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
hmm, I was thinking that this would make vdradmin show shows that have timers set in the timeline window even if folders are used. But the recordings will will be showing names like Thu_04.02.2010-20:00 because the parent folder is the show name. On 2/28/2010 12:59 PM, Udo Richter wrote: Am 28.02.2010 16:07, schrieb Klaus Schmidinger: - The file name in the Timers menu now shows only the base name of the recording without the folder path (if any). Otherwise with long folder paths the actual recording name was not visible at all. If I understand that correctly, then many of my repeating recordings will soon be named TITLE or EPISODE only in the timer menu, because many of my timers use the scheme ShowName~EPISODE. I prefer to add ~EPISODE or ~TITLE individually instead of of using the Use episode name option. Maybe I can come up with a smarter scheme on how to shorten the timer name for display. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.13
VDR developer version 1.7.13 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.13.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.12-1.7.13.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.7.12: - Updated the Italian OSD texts (thanks to Diego Pierotto). - Changed the position of Sirius 4 to S4.8E in sources.conf (thanks to Alexander Gross). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Moved the declaration of cMenuCommands to menu.h, so that plugins can use it. - Added a note to the MANUAL, saying that adding new transponders only works if the EPG scan is active (suggested by Halim Sahim). - Improved handling frames at the beginning and end of a recording in cDvbPlayer for devices with large buffers (thanks to Reinhard Nissl). - Implemented cDeviceHook to allow plugins more control over which device can provide which transponder (thanks to Reinhard Nissl). - Implemented cDevice::GetCurrentlyTunedTransponder() (thanks to Reinhard Nissl). - Moved strictly necessary Makefile options into Make.global, which is included by all plugins (thanks to Paul Menzel). The Makefiles of existing plugins should be modified like this: --- PLUGINS/src/hello/Makefile 2009/10/18 14:00:07 2.1 +++ PLUGINS/src/hello/Makefile 2010/02/06 14:50:03 2.2 @@ -18,7 +18,7 @@ ### The C++ compiler and options: CXX ?= g++ -CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses +CXXFLAGS ?= -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses ### The directory environment: @@ -26,6 +26,10 @@ LIBDIR = ../../lib TMPDIR = /tmp +### Make sure that necessary options are included: + +include $(VDRDIR)/Make.global + ### Allow user defined options to overwrite defaults: -include $(VDRDIR)/Make.config - Added device definitions to the diseqc.conf file format, so that certain satellite positions can be limited to a given list of devices. This obsoletes the SOURCECAPS patch. - Keeping subtitles visible when pausing replay (thanks to Rolf Ahrenberg). - Fixed adding new transponders in case there is only a single channel in the channel list (reported by Halim Sahin). - The file name in the Timers menu now shows only the base name of the recording without the folder path (if any). Otherwise with long folder paths the actual recording name was not visible at all. - Updated the Romanian OSD texts (thanks to Lucian Muresan). - Exported some libsi functions (thanks to Lucian Muresan). - Improved scalability of the default skins. - Fixed the German translation of Folder name must not contain '%c'! (thanks to Frank Schmirler). - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Plugins can now define new sources. In order to implement this, the following changes were made: + The transponder parameter string is no longer interpreted by cChannel, but rather stored as is and used only by the respective device. That way plugins can use a channel's parameter string to store arbitrary data (see vdr.5). + The new class cSourceParam can be used by plugins to define new sources, and to implement OSD items that will be used in the channel editor for editing the source specific parameters of a channel (see dvbdevice.c for an example of how this is done for the default DVB devices). + Purely numerical values are no longer accepted in the 'source' parameter of a channel. This obsoletes the PLUGINPARAM patch. - Updated the Lithuanian OSD texts (thanks to Valdemaras Pipiras). - cSafeFile::Close() now flushes the file (suggested by Stephan Austermuhle). - The option Setup/DVB/Use Dolby Digital now only controls whether Dolby Digital tracks appear in the Audio menu. Dolby Digital is always recorded. This obsoletes the DOLBYINREC patch. Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
Am 28.02.2010 16:07, schrieb Klaus Schmidinger: - The file name in the Timers menu now shows only the base name of the recording without the folder path (if any). Otherwise with long folder paths the actual recording name was not visible at all. If I understand that correctly, then many of my repeating recordings will soon be named TITLE or EPISODE only in the timer menu, because many of my timers use the scheme ShowName~EPISODE. I prefer to add ~EPISODE or ~TITLE individually instead of of using the Use episode name option. Maybe I can come up with a smarter scheme on how to shorten the timer name for display. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
