Reserve device for Live-Tv

Message ID 50D1B898.8010104@gmx.de
State New
Headers

Commit Message

Ingo Prochaska Dec. 19, 2012, 12:52 p.m. UTC
  Am 19.12.2012 10:36, schrieb EikeSauer@t-online.de:
>
> clue how to accomblish this...
> There's a define LIVEPRIORITY somewhere in the code. If you would
> set it to MAXPRIORITY and recompile, you might get what you need.
> Recorders couldn't claim the device used for live viewing becausethey
> would have lower priority. Disclaimer: I didn't try it.
>
> Ciao,
>    Eike
>
After a first test: it works. I have three devices - I started two 
live-recordings and generated a timer within the next 3 minutes watching 
a fourth transponder. When the timer should kick in nothing happens. So 
far - so great.

But really nothing happens: no channelswitch - but also no conflict 
warning or any info about not serving the timer. So this might be the 
first step in direction to solve this (social ;) ) problem. Perhaps a 
LIVEPRIORITY of 98 makes sense here, so that you can configure timers 
that are more important then viewing live TV.

Klaus, I understand that you do not want to introduce more features 
before 2.0 and I understand that this is a very marginal issue. But if 
you have an idea, how to get vdr to spill a message about this 
situation, I would be very glad if you could help us people with too 
many timers out.

Regards, Ingo

  #define TRANSFERPRIORITY  (LIVEPRIORITY - 1) // priority used for 
actual local Transfer Mode
  #define IDLEPRIORITY      (MINPRIORITY - 1)  // priority of an idle device
  #define MAXLIFETIME       99
  

Comments

Klaus Schmidinger Dec. 19, 2012, 1:02 p.m. UTC | #1
On 19.12.2012 13:52, Ingo Prochaska wrote:
> Am 19.12.2012 10:36, schrieb EikeSauer@t-online.de:
>>
>> clue how to accomblish this...
>> There's a define LIVEPRIORITY somewhere in the code. If you would
>> set it to MAXPRIORITY and recompile, you might get what you need.
>> Recorders couldn't claim the device used for live viewing becausethey
>> would have lower priority. Disclaimer: I didn't try it.
>>
>> Ciao,
>>    Eike
>>
> After a first test: it works. I have three devices - I started two live-recordings and generated a timer within the next 3 minutes watching a fourth transponder. When the timer should kick in nothing happens. So far - so great.
>
> But really nothing happens: no channelswitch - but also no conflict warning or any info about not serving the timer. So this might be the first step in direction to solve this (social ;) ) problem. Perhaps a LIVEPRIORITY of 98 makes sense here, so that you can configure timers that are more
> important then viewing live TV.
>
> Klaus, I understand that you do not want to introduce more features before 2.0 and I understand that this is a very marginal issue. But if you have an idea, how to get vdr to spill a message about this situation, I would be very glad if you could help us people with too many timers out.

Well, since I won't adopt any such change (mainly because it makes things more
complex than they already are) I'm afraid you're on your own here.
You might want to look at

               if (!cRecordControls::Start(Timer))
                  Timer->SetPending(true);
               else
                  LastTimerChannel = Timer->Channel()->Number();
               }

in vdr.c, where SetPending() is called. If you want to issue a message
whenever a timer can't start, that might be a place to dig in.

Klaus
  
Ingo Prochaska Dec. 21, 2012, 12:20 p.m. UTC | #2
Hello,

Am 19.12.2012 14:02, schrieb Klaus Schmidinger:
> Well, since I won't adopt any such change (mainly because it makes 
> things more
> complex than they already are) I'm afraid you're on your own here.
> You might want to look at
>
>               if (!cRecordControls::Start(Timer))
>                  Timer->SetPending(true);
>               else
>                  LastTimerChannel = Timer->Channel()->Number();
>               }
>
> in vdr.c, where SetPending() is called. If you want to issue a message
> whenever a timer can't start, that might be a place to dig in.

yes, a first test shows it that works here. Then I've tried to check the 
code and the interaction between epgsearch (timerconflict) and vdr to 
implement a timerconflict warning on 2 different transponders (with 3 
cards available) and stumbled over code I did not have a clue, what it 
does...

To come to an end (remember it's December, the 21st in 2012!), I decided 
to believe in "keep it simple", and just push the priority for live 
recordings and use the pausebutton for important broadcastings.

Thanx Klaus and thanx to everybody for the suggestions - if I decide to 
dig deeper in the "premature" timerconfict warning I will report.

Regards, Ingo
  

Patch

diff --git a/config.h b/config.h
index 65e85bc..5d32d11 100644
--- a/config.h
+++ b/config.h
@@ -45,7 +45,9 @@ 

  #define MAXPRIORITY       99
  #define MINPRIORITY       (-MAXPRIORITY)
-#define LIVEPRIORITY      0                  // priority used when 
selecting a device for live viewing
+//try to rserve 1 Device for live-TV exclusivly
+#define LIVEPRIORITY      MAXPRIORITY                  // priority used 
when selecting a device for live viewing
+//#define LIVEPRIORITY      0                  // priority used when 
selecting a device for live viewing