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 Austermu"hle). - 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
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
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
On 28.02.2010 20:59, 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.
Would it be ok if I change it so that the full name is displayed (like before) if the string that would be displayed with the new mechanism is "TITLE" or "EPISODE"?
Klaus
On 07.03.2010 15:05, Klaus Schmidinger wrote:
On 28.02.2010 20:59, 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.
Would it be ok if I change it so that the full name is displayed (like before) if the string that would be displayed with the new mechanism is "TITLE" or "EPISODE"?
While we're at it, here's the patch right away.
Klaus
Am 07.03.2010 15:05, schrieb Klaus Schmidinger:
On 28.02.2010 20:59, Udo Richter wrote:
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.
Would it be ok if I change it so that the full name is displayed (like before) if the string that would be displayed with the new mechanism is "TITLE" or "EPISODE"?
I thought of that too, but as Timothy wrote, search timers also tend to generate less useful names like "Thu_04.02.2010-20:00" or all the useless stuff that TV stations use as episode name.
A better way would be to shorten the folder part and the name dynamically, so that at least a part of both is visible. Like shortening aaaaaaa~bbbbbbbb~cccccccc~dddddddd to aaaa...cccc~dddd...
Cheers,
Udo
On 07.03.2010 17:06, Udo Richter wrote:
Am 07.03.2010 15:05, schrieb Klaus Schmidinger:
On 28.02.2010 20:59, Udo Richter wrote:
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.
Would it be ok if I change it so that the full name is displayed (like before) if the string that would be displayed with the new mechanism is "TITLE" or "EPISODE"?
I thought of that too, but as Timothy wrote, search timers also tend to generate less useful names like "Thu_04.02.2010-20:00" or all the useless stuff that TV stations use as episode name.
Well, that's the problem of whoever generates the search timer ;-)
A better way would be to shorten the folder part and the name dynamically, so that at least a part of both is visible. Like shortening aaaaaaa~bbbbbbbb~cccccccc~dddddddd to aaaa...cccc~dddd...
I can give you a setup option that switches between the old and the new version - if it really turns out to be necessary. Anything else would probably quickly become "rocket science" ,-)
Klaus
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:
This obsoletes the PLUGINPARAM patch.
- 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.
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.
On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch dvb@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. ;)
On 03/03/10 13:35, VDR User wrote:
On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch dvb@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..
On Wed, 03 Mar 2010 15:56:06 -0600 Rob Davis rob@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.
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. Hanischdvb@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..
Am 03.03.2010 20:35, schrieb VDR User:
On Wed, Mar 3, 2010 at 10:47 AM, L. Hanischdvb@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.
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. Hanischdvb@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
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
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
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
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
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
On 04.03.2010 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.
Ok, so 'I' is assigned to "IPTV".
Klaus
On 03.03.2010 19:47, 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?
The assigned sources are documented in VDR/sources.conf.
'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?
Yes.
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?
'A' will be reserved for ATSC.
So I think it would be better to take *'V' = 'analog video'*, since pvrinput is basically an interface to v4l-devices.
Ok, I have no objections to assigning 'V' to pvrinput.
What are you thinking?
I think it is a bad idea to hijack a thread ;-)
Klaus
-
Klaus Schmidinger -
L. Hanisch -
Rob Davis -
Rolf Ahrenberg -
Timothy D. Lenz -
Tony Houghton -
Udo Richter -
VDR User