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
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 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
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
There is a plugin for ATSC: http://www.fepg.org/atscepg/ http://dvbn.happysat.org/viewtopic.php?f=17&t=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. Hanisch 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
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. Hanisch 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
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
On Wed, 03 Mar 2010 15:56:06 -0600 Rob Davis 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
Am 03.03.2010 20:35, schrieb VDR User: On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch 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 03/03/10 13:35, VDR User wrote: > On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch 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
On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch 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
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
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
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
