Special VPIDs to allow recording radio channels

This commit is contained in:
Klaus Schmidinger 2002-02-03 16:22:05 +01:00
parent deb9f88710
commit da56a94dbf
4 changed files with 21 additions and 2 deletions

View File

@ -185,3 +185,6 @@ Andreas Gebel <andreas@xcapenet.de>
Davide Achilli <davide@objsystem.it>
for pointing out a bug in error handling while establishing an SVDRP connection
Michael Paar <mpaar@uumail.de>
for enabling recording of radio channels

View File

@ -24,7 +24,7 @@ Video Disk Recorder File Formats
- Polarization (one of 'h', 'H', 'v', 'V') **
- Diseqc number **
- Symbol rate ***
- Video PID
- Video PID (set to '0' for radio channels, '1' for encrypted radio channels)
- Audio PID (either one number, or two, separated by a comma)
If this channel also carries Dolby Digital sound, the Dolby PIDs follow
the audio PIDs, separated by a semicolon, as in "...:101,102;103,104:..."

View File

@ -962,3 +962,8 @@ Video Disk Recorder Revision History
'start + (Setup.MarginStart * 2) + 1)' in order to have a better chance of
hitting the right record in case of an instant recording. Timers that start
further in the future should always be programmed via the "Schedules" menu.
- The special VPIDs '0' and '1' are now used to enable recording radio channels.
Actually '0' should be enough, but '1' must be used with encrypted channels
(driver bug?). Note, though, that since VDR is mainly a *video recorder*, some
features like, e. g., the progress display, may not work as expected with
radio recordings. Thanks to Michael Paar.

13
remux.c
View File

@ -8,7 +8,7 @@
* the Linux DVB driver's 'tuxplayer' example and were rewritten to suit
* VDR's needs.
*
* $Id: remux.c 1.7 2002/02/02 12:54:30 kls Exp $
* $Id: remux.c 1.8 2002/02/03 16:20:37 kls Exp $
*/
/* The calling interface of the 'cRemux::Process()' function is defined
@ -555,6 +555,17 @@ XXX*/
return Result ? resultBuffer : NULL;
XXX*/
// Special VPID case to enable recording radio channels:
if (vPid == 0 || vPid == 1 || vPid == 0x1FFF) {
// XXX actually '0' should be enough, but '1' must be used with encrypted channels (driver bug?)
// XXX also allowing 0x1FFF to not break Michael Paar's original patch,
// XXX but it would probably be best to only use '0'
*PictureType = I_FRAME;
Result = resultDelivered = resultCount;
return Result ? resultBuffer : NULL;
}
// Check if we're getting anywhere here:
if (!synced && skipped >= 0) {