New PRIORITY Handling since 1.7.25

[hondansx]

Hi Marten,

can you adopt this changes?

Code Select Expand


Changes in 1.7.25
- Revised priority handling to allow receivers with a priority that is lower than
  that of live viewing (with suggestions from Frank Schmirler):
 
....

The default priority of a cReceiver is now MINPRIORITY (-99).

  A device that is used only for live viewing (no matter whether it's in Transfer
    Mode or real live mode) now has priority TRANSFERPRIORITY (-1).

  .....



Problem is that if a timer is starting vompclient gets a channel not available message. Not a real  problem but should be fixed.

BTW:
Should be mentioned. Many thanks for your great work on this project. Works every day better.

Walter

[MartenR]

Problem is that if a timer is starting vompclient gets a channel not available message. Not a real  problem but should be fixed.

The question is how.
I mean a timer should have priority over the vompclient. You do not wish, that zapping kills your recordings right??
I mean it was always like this at my home, that a timer kicks out someone who watches a recording? 
EDIT: (Do you mean since the default is 0?)
EDIT2: I have check this, you probably only what that the sanity checks are modified so that negative values are accept. This should be easy, but I am running an old vdr version I need someone to test it.


Marten

[MartenR]

Code Select Expand

int VompClientRRProc::processStartStreamingChannel()
{
  if (x.lp)
  {
    log->log("RRProc", Log::ERR, "Client called start streaming twice");
    return 0;
  }
 
  log->log("RRProc", Log::DEBUG, "req->dataLength = %i", req->dataLength);
  ULONG channelNumber = ntohl(*(ULONG*)req->data);

  cChannel* channel = x.channelFromNumber(channelNumber);
  if (!channel)
  {
    resp->addULONG(0);
    resp->finalise();
    x.tcp.sendPacket(resp->getPtr(), resp->getLen());
    return 1;
  }

  // get the priority we should use
  int fail = 1;
  int priority = x.config.getValueLong("General", "Live priority", &fail);
  if (!fail)
  {
    log->log("RRProc", Log::DEBUG, "Config: Live TV priority: %i", priority);
  }
  else
  {
    log->log("RRProc", Log::DEBUG, "Config: Live TV priority config fail");
    priority = 0;
  }

  // a bit of sanity..
#if VDRVERSNUM < 10725
  if (priority < 0) priority = 0;
#else
  if (priority < -99) priority = -99;
#endif
  if (priority > 99) priority = 99;

  log->log("RRProc", Log::DEBUG, "Using live TV priority %i", priority);
  x.lp = MVPReceiver::create(channel, priority);

  if (!x.lp)
  {
    resp->addULONG(0);
    resp->finalise();
    x.tcp.sendPacket(resp->getPtr(), resp->getLen());
    return 1;
  }

  if (!x.lp->init(&x.tcp, req->requestID))
  {
    delete x.lp;
    x.lp = NULL;
    resp->addULONG(0);
    resp->finalise();
    x.tcp.sendPacket(resp->getPtr(), resp->getLen());
    return 1;
  }

  resp->addULONG(1);
  resp->finalise();
  x.tcp.sendPacket(resp->getPtr(), resp->getLen());
  return 1;
}

int VompClientRRProc::processStopStreaming()
{
  log->log("RRProc", Log::DEBUG, "STOP STREAMING RECEIVED");
  if (x.lp)
  {
    x.lp->detachMVPReceiver();
    delete x.lp;
    x.lp = NULL;
  }
  else if (x.recplayer)
  {
    x.writeResumeData();

    delete x.recplayer;
    delete x.recordingManager;
    x.recplayer = NULL;
    x.recordingManager = NULL;
  }

  resp->addULONG(1);
  resp->finalise();
  x.tcp.sendPacket(resp->getPtr(), resp->getLen());
  return 1;
}
Here is a suggestion of a server side change, can you test it and create a patch. client side will come later.

Marten

[MartenR]

You can try this in vopts client side. I will commit the client side, if it works for you:

option = new Option(8, "VDR-Pri 0=OK !See forums!",  "General",  "Live priority",      Option::TYPE_INT,  199, -1, -99, NULL);

Marten

[hondansx]

Problem is that if a timer is starting vompclient gets a channel not available message. Not a real  problem but should be fixed.

The question is how.
I mean a timer should have priority over the vompclient. You do not wish, that zapping kills your recordings right??

That's surely true, but I should mentioned, that it should not happen in a multidbvcard environment, where resources are free and vdr will know about this.

I mean it was always like this at my home, that a timer kicks out someone who watches a recording?

Not with more than one dbv card. ;-)

EDIT: (Do you mean since the default is 0?)

Yes

EDIT2: I have check this, you probably only what that the sanity checks are modified so that negative values are accept. This should be easy, but I am running an old vdr version I need someone to test it.

Maybe its time to update to a newer version of your vdr. ;-) I can test it. Thanks about this

[MartenR]

Maybe its time to update to a newer version of your vdr. ;-)

Yes, you are right, but this takes probably a day with testing and I used all my time on weekends for vomp the last weeks to months.

Martem

[hondansx]

Priority changes within vomp/vdr is working now, but I have to test further, if it solves the channel not available problem. Maybe this are other changes within vdr.
I give back feedback later about this.

[Kleo]

Sorry for bringing up this old thread.

I'm trying to replace two old MVPs by vomp-clients on raspberries and I'm having issues
configuring the VDR prio correctly.

Since switching to the new vdr version and vomp-server (vdr 2.0.3 + vompserver 0.4.0)
- to get the RPi working - I have Live-TV issues in the vomp-client (on the RPi AND the old MVPs)
when a recording starts on the server.

The server has two separate Technisat DVB-S cards and should have an available tuner when a
single recording starts.

Nevertheless I get a 'channel unavailable' message on thr RPi/MediaMVPs when a recording starts.
I have to go to a different channel and back to my original channel to get Live-TV back.

That didn't happen on the former Ubuntu 9.04 server with older vdr and vomp-server versions.

For completeness I have to say that there are the streamdev-server and xineliboutput-plugins
installed on the server. They are not used when that happens, but loaded in vdr. I'm not sure
whether their updated versions include changes to the handling of devices. That's why I'm not
exactly sure if it's actually a vomp-server/client issue.

But I'm hoping one of you can shed some light on the Prio setting and what to expect from a dual
tuner server.

Best regards, Alex