streamdev im Mischbetrieb 1.2.x und 1.3.x

Hi,

ich habe folgende Konstellation:
- Client mit VDR 1.2.5 und streamdev-0.3.3-pre4-gen, DVB-S
- Server mit VDR 1.3.23 und streamdev-cvs von vor einiger Zeit, DVB-T

Das CVS kompiliert nicht unter 1.2.5, das pre4 umgekehrt nicht im Server.

Die folgenden Probleme beziehen sich vermutlich z.T. auf Inkompatibilitäten zwischen den Plugins, und z.T. zwischen den VDR-Versionen. Mich würde interessieren, was dazu so bekannt ist, welche Konstellationen klappen, und was man vielleicht doch noch tun kann, um Details auch in meiner Konstellation noch zu verbessern.

Diese Anfrage hat übrigens eine Vorgeschichte, wens interessiert:
http://vdrportal.de/board/thread.php?threadid=37888&sid=

• Streaming funktioniert recht gut: die in der channels.conf eingefügten Kanäle vom Server (natürlich unter höheren Programmplätzen) kann ich ansehen. Normal durchschalten liessen sie sich allerdings erst nach einer Source-Änderung wie hier beschrieben:
  http://www.vdr-portal.de/board/thread.php?threadid=37828&sid=
  

  
  

• Remote Recordings: hier ist nichts zu sehen. Im Log: Couldn't fetch recordings from ...
  Dies stört mich nicht weiter, da ich die Aufnahmen über Netz-Mount (also direkt im Filesystem) ansehe. Interessant wärs allerdings, wenn man darüber in den remote recordings einen Schneidevorgang (auf dem Server) auslösen könnte - wenns funktionieren würde - wäre das so? Kann man über diesen Menüpunkt normalerweise entfernte Aufnahmen ansehen?
  

  
  

• EPG: das klappt nicht:
  ERROR: unexpected tag while reading EPG data: V 1125849900
  ERROR: Streamdev: Parsing EPG data failed
  Hier ist wohl das Format vom 1.3er VDR neu und vom 1.2er nicht mehr interpretierbar? Oder könnte man da was machen? Wäre sehr gut, da ansonsten Timerprogrammierung nat. mehr als mühsam ist.
  

  
  

• Remote Timer: das wichtigste. Ich sehe vorhandene remote Timer und kann diese löschen. Allerdings wird als Programmplatz der vom Server angezeigt. Beim Editieren müsste ich dann den richtigen Programmplatz vom Client nehmen - sonst Fehlermeldung auf dem Server "channel ... not defined". Aber auch wenn ich das mache, bleibt ein Editieren wirkungslos! D.h. wenn ein Timer nicht genau passt, muss ich löschen und neuanlegen. Denn Anlegen klappt. Allerdings mangels EPG sehr aufwendig (Namenseingabe).

Soweit also der Zustand - im Prinzip habe ich damit schon mal mein Ziel erreicht, den Server-VDR über den Client fernzusteuern (Timer) - allerdings noch etwas unkomfortabel. Bin dankbar für alle Hinweise, wie man das nun noch verbessern könnte. Allerdings bis auf weiteres unter Beibehaltung der Server- und Client-VDR-Versionen.

Noch zwei Beobachtungen nachgeliefert:

- Ein remote Timer, der gerade aufnimmt, ist als solcher nicht erkennbar. Ausser über die Eigenschaft, dass er nicht gelöscht werden kann (kein Effekt), d.h. laufenden Aufnahmen auf dem Server lassen sich nicht abbrechen

- Trotz fehlenden EPGs für die remote channels kann man auf einem lokalen Kanal den "remote schedule" aufrufen und bekommt das lokale EPG des laufenden Kanals angezeigt. Da man alle DVB-T Kanäle auch unter DVB-S hat, könnte man dadurch nur durch manuelle Änderung des Kanals im Timer doch bequem aus dem EPG heraus programmieren. Nur leider wird auf diesem Weg der Name der Sendung nicht in den Timer übernommen!

Tja, nach längerer Debugging-Session (meine C/C++ Kenntnisse sind nicht mehr ganz frisch): der Grund für die Nicht-Übernahme des Filenamens aus dem EPG in den remote-Timer ist gefunden und behoben.

In client/remote.c im Zuweisungsoperator:
cRemoteTimer &cRemoteTimer::operator=(const cRemoteTimer &Timer)
wird der Filename nicht mitkopiert. Einzufügen ist:
strncpy(m_File, Timer.m_File, sizeof(m_File));

Sonst scheitert in client/menu.c in
cStreamdevMenuEditTimer::cStreamdevMenuEditTimer(cRemoteTimer *Timer, bool New)
die Zuweisung
m_Data = *m_Timer;
bzw. der Filename fehlt eben.

Habe das bei mir im 0.3.3-pre4-geni gemacht, aber ist auch in der CVS-Version noch so! Hat das noch niemanden gestört!? Kann doch eigtl. bei niemandem je so funktioniert haben.
Gibts einen Maintainer dem ich das zukommen lassen sollte?

Ist zwar immer noch etwas holprig (neue Timer immer erst nach zweimal remote-timer-menu Aufruf sichtbar und was ich so oben alles beschrieben habe), aber langsam wird die Sache praktikabel.

Hallo mac66,

Geht bei Dir denn EPG? Oder machst Du es genau wie ich: das lokale EPG
benutzen (über remote schedule auf einem lokalen Kanal) und dann von
Hand den Kanal ändern?
Also ich habs ja oben alles ganz genau beschrieben, wie es bei mir läuft.
Und zwar dass ich neue Timer anlegen kann, aber keine editieren. Und
in meinem letzten Post steht auch, dass ich nach Anlegen eines Timers
den erst mal nicht bei den remote Timers sehe - ich muss noch zweimal
den Menupunkt aufrufen, dann ist der Timer sichtbar. Probiers mal, mit
etwas Geduld.. oder geht es bei Dir dann wirklich gar nicht?
Am besten prüft man auf dem Server direkt ob der Timer da ist oder nicht.
Du hattest mich doch auf die Streaming Controls erst gebracht und
erzählt, dass es bei Dir läuft!?

Ich habe generell schon vor, auch der Sache mit dem Editieren noch weiter
nachzugehen, aber es ist schon etwas mühsam so von Null und v.a. habe
ich zu wenig Zeit Aber wann immer ich neue Erkenntnisse oder Lösungen
habe, melde ich mich hier.

Dass wir die einzigen sind scheint so, aber vielleicht gibt ja doch demnächst
noch der ein oder andere ein Lebenszeichen.

Das CVS hat sich übrigens seit Anfang Juli nicht verändert.

Nach stundenlangem Debugging wieder eine kleine Erkenntnis: warum das Timer-Editieren nicht funktioniert. Es wird der Tag nicht korrekt vom remote-Timer übernommen, da steht 0 (hätte mir nat. auch direkt auffallen können..). Setzt man den Tag wie den Kanal per Hand korrekt, klappt auch das Ändern vorhandener Timer.

Grund für den falschen Tag ist, dass der Server (1.3.x) den Tag in der Form 2005-09-09 schickt, was die ParseDay-Funktion in client/remote.c nicht verkraftet. Ich habe nicht durchschaut was die genau treibt, bei mir sieht sie jetzt einfach nur noch so aus:

int cRemoteTimer::ParseDay(const char *s, time_t *FirstDay) {
  char *tail, *tail1;
  int d = strtol(s, &tail, 10);
  if (*tail && tail != s)
  {
    tail1 = tail + 1;
    d = strtol(tail1, &tail, 10);
    tail1 = tail + 1;
    d = strtol(tail1, &tail, 10);
  }
  return d;
}

Damit wird der Tag korrekt herausgeparst.

Dass bei Dir EPG geht (also remote schedule auch auf den remote channels mit den Server-EPG-Daten) deutet also darauf hin, dass entweder die gleiche Plugin-Version auf beiden Seiten hilft, oder aber viel wahrscheinlicher eben die gleiche VDR-Version - denn wie gesagt kann bei mir das EPG nicht verarbeitet werden, es käme offenbar schon über die Leitung daher.
Das Editieren der Timer ging bei Dir auch nicht? Denkbar dass für das Format 200x-y-z das Plugin verantwortlich ist, aber bei gleicher Version wärs schon seltsam.

Mein Standort ist die andere Seite von München, wohl gut 100km weg. Aber das Forum ist doch ein gutes Mittel zum Austausch. Werde jetzt wieder erst irgendwann nächste Woche zum weitermachen kommen.

So, nun habe ich nochmal einige Macken behoben. Welche davon auf den Mischbetrieb zurückgehen und welche auch etwa Du, mac66, zu beklagen hast, das würde mich interessieren.

Generell sollte man im client/socket.c unter Command() bzw. Expect() die ausgehenden Kommandos OUT und die Ergebnisse IN loggen, um genauer nachzuvollziehen, was vor sich geht. Allerdings sollte man EPG-Daten (Expect = 215) ausnehmen, die müllen das Log ordentlich voll.
Ich konzentriere mich auf den Client (0.3.3-pre4-geni im VDR 1.2.5), evtl. Fehlverhalten im Server bleibt erstmal unberücksichtigt und wird ggf. im Client umgangen.

• EPG:
  Um das EPG vom 1.3er Server zu verkraften: V-Zeilen (offenbar neue Daten zum VPS - seit wann gibts denn VPS und kann man das nutzen?) ausblenden:
  
  
  Code

  client/socket.c, SynchronizeEPG():
  
  
          while ((res = Expect(215, &buffer))) {
                  if (buffer[3] == ' ') break;
  #if VDRVERSNUM < 10300
                  if (buffer[4] == 'V') continue;
  #endif
                  fputs((const char*)buffer + 4, epgfd);
                  fputc('\n', epgfd);
          }

  Alles anzeigen

  
  

• Nun kann man direkt aus dem EPG der remote channels timer programmieren, ohne noch unbedingt was von Hand anpassen zu müssen. Dann werden diese allerdings nicht übernommen.
  Grund: beim Record() wird der Timer nicht als "neu" angelegt, und "neu" reicht auch nicht als Grund zum Speichern - es wird nur auf eine Änderung geprüft. Zwei Stellen im Code:
  
  
  Code

  client/menu.c:
  
  
  eOSState cStreamdevMenuSchedule::Record(void)
    ..
    return AddSubMenu(new cStreamdevMenuEditTimer(timer, true));
    ..
  
  
  eOSState cStreamdevMenuEditTimer::ProcessKey(eKeys Key)
    ..
    if (m_AddIfConfirmed || (m_Data != *m_Timer)) {
          // Timer has changed or is new
          if ((success = ClientSocket.SaveTimer(m_Timer, m_Data)))
    ..

  Alles anzeigen

  
  

• Als nächstes wird immer nach Neuanlage oder Editieren eines Timers der neue Zustand erst nach zweimaligem Auslesen der server-Timer angezeigt. Nach dem ersten LSTT kommt immer garnichts vom Server, und die Verbindung zum Server wird neu aufgemacht. Also einfach ggf. zweimal abholen:
  In socket.c, LoadTimers(): Schleife um den Kommando-Block, die bei erstmaligem Versagen erneut LSTT anfordert.
  

  
  

• Aufnehmende Timer werden nicht erkannt. Damit diese wie üblich mit # markiert werden (sie können dann aber immer noch nicht gelöscht / Aufnahme abgebrochen werden):
  
  
  Code

  menu.c / void cStreamdevMenuTimerItem::Set(void)
   einkommentieren: m_Timer->Recording() ? '#' : '>',
  
  
  remote.h/.c als Funktion einfügen:
   bool cRemoteTimer::Recording(void) {
     return ((m_Active & 8) > 0);
   }

  
  

• Schliesslich werden die Kanäle der Server-Timer nur als Kanalnummer übertragen. Das Plugin kann nicht wissen, welcher Kanal auf dem Client korrespondiert. Also macht man einen Hack, der einen festen Offset vorgibt: zB Offset 100: Server 1 = ARD -> Client 101 = Server-ARD.
  
  
  Code

  remote.c, cRemoteTimer::cRemoteTimer(const char *Text):
   ..
   if (isnumber(tmpbuf))
     m_Channel = Channels.GetByNumber(strtoul(tmpbuf, NULL, 10) + 100);

  
  Danach wird der korrekte Kanal angezeigt und beim Editieren vorgegeben.
  

Damit ist nun erstmal das Gröbste erledigt und ich kann vernünftig mit den remote Timern arbeiten.

Hi mac66,

Ich habe die modifizierten Files aus dem Verzeichnis client von 0.3.3-pre4-geni
(4 Stück) angehängt. Viel Erfolg!

Nachtrag: wenn Du die 4 Files in client/ direkt nimmst (also ersetzt), hast Du den gleichen Stand wie ich derzeit. Es steht dann auch die Netzwerk-Kommunikation im Log (IN/OUT). Allerdings musst Du mindestens die Stelle wieder rückgängig machen, wo ich die remote-channels mit +100 ermittle.

Hi mac66,

aus now / next hatte ich es noch nicht probiert. Nicht übernommen wird nur, wenn man garnichts ändert - Grund war der gleiche wie beim normalen Schedule: der Timer wird nicht als "neu" instanziiert. Man muss in Zeile 400 von menu.c die gleiche Änderung machen wie in Zeile 574: ,true anhängen!

Der Restart bedeutet, dass der VDR abschmiert - im runvdr-Skript wird er in einer Endlos-Schleife dann gleich wieder neu gestartet. Ich muss leider sagen, dass es auch bei mir ziemlich zuverlässig zum Crash kommt, wenn man etwas mit dem streamdev-client macht - also nicht sofort und auch nicht total reproduzierbar, aber doch recht schnell. Besonders schwerverdaulich scheint ein EPG-Sync zu sein. Im Log steht auch bei mir nichts, was den Crash erklären würde. Man sollte also besser nicht mit dem Plugin arbeiten, wenn grade eine Aufnahme auf dem Client läuft.

Na denn gute Nacht..

Zitat

Original von mac66
Client stürzt jetzt nur noch ab, wenn der Server Timer über Programm gesetzt wurde.
Aus "now" oder "next" einen Timer setzen und die Probleme sind weg.

Sehr seltsam. Möglicherweise hast Du automatisches EPG Sync konfiguriert, und wenn Du den schedule aufrufst wird der ausgelöst, während bei now/next noch genug Daten vom letzten mal da sind? Ich würde vorschlagen das nochmal über einen längeren Zeitraum zu beobachten und dann nochmal von den Erkenntnissen zu berichten.