Beiträge von hivdr

Zitat

Original von Hemonu
Ich nutze seit kurzem einen ACER Revo 3600 zusammen mit einer TechnoTrend S2-3600 Box. Der Rechner ist eine schnuckelig kleine und angenehm leise Box mit einem Mini-ITX ION-Board drin. Funktioniert einwandfrei sowohl unter VDR 1.6.0 als auch unter 1.7.7 (mit den üblichen Problemen).

Da ich die Kombination im Moment auch ausprobiere, aber mit EasyVDR, ist im dortigen Forum folgende Frage aufgekommen: welchen Treiber / Treiber-Version nutzt Du für die S2-3600? Unter linuxtv ist die Kiste ja als nicht unterstützt eingetragen..

In meinem Fall klappt das mit einem VDR 1.7 zwar in Ansätzen mit dem Bild, habe aber zB keinen Ton und Ruckler bei Anixe/AstraHD sowie Tonaussetzer beim Festival- und ARD-Test. EasyVDR kann HD nur mit dem 1.7.

Ist obiges so zu verstehen, dass HD mit dem VDR 1.6 wirklich perfekt klappt? Diese e-Tobi Distribution, ist das ähnlich EasyVDR für out-of-the-box gedacht oder eher eine Selbstbau-Grundlage?

Danke und Grüsse
hivdr

11bo11

Dolle Sache. Genau so stelle ich mir das auch vor - nur noch mit Twin-Tuner.
Und Terabyte-Platte muss es schon sein, in das Gehäuse scheint ja auch 3.5" reinzupassen. Wo bekommt man das Gehäuse denn in D?

Was mich noch sehr interessieren würde: wie verlief die Installation?
Du schreibst sheep-iso - also das was im EasyVDR-Forum HDTV unter "HD-RePack2: Alphatest (!! updated !!)" im ersten Post verlinkt ist?
Installiert und alles läuft auf Anhieb? Oder eher tagelange Bastelei..?
In letzterem Fall wären ein paar Hints für angehende Nachahmer schön.

Grüsse
hivdr

Das klingt ja alles sehr vielversprechend hier.

Nachdem mein Uralt-VDR nun schon über 6 Jahre läuft (DVB-S, FF, VDR 1.1 - dazu seit 4 Jahren ein headless DVB-T im Server, VDR 1.3), wird es höchste Zeit für was neues in HDTV. Plane also in absehbarer Zeit auch so ein ION Board mit PCIe Twin-DVB-S2-Karte (offenbar noch nicht lieferbar, anderer Thread).

Um schon mal wieder ein bisschen zu üben, hab ich mir nun so einen Revo 3600 besorgt, erst mal mit einem einfachen DVB-T-Stick. Und ich seh schon, das ganze wird wieder Zeit ohne Ende verschlingen.. bin doch schon zu lange nicht mehr bei der Musik. Von wegen EasyVDR out of the box, da hab ich jede Menge Probleme - aber dazu frage ich wohl besser mal im easyVDR-Forum nach (Live-CD 0.6.07).

Grundsätzlich habe ich ein Bild, und v.a. kann ich Aufnahmen von den alten beiden VDR über Netz ansehen. Dazu gewinne ich ein zwiespältiges Bild:
Einerseits ist das Bild über HDMI doch sehr viel detailreicher, nicht so vermatscht wie über den FF-Cinch-Video-Out. Ohne Overscan (muss beim Toshiba 42z3030d leider jedesmal wieder umgeschaltet werden) auch viel mehr Bildfläche. Jedenfalls bei eher hochbitratigen Sendern wie ZDF (DVB-T) wirklich das klar bessere Bild.
Andererseits habe ich in anderen Aufnahmen (Pro7 DVB-S, ist ja noch viel hochbitratiger) übelste Interlace-Kämme! Daran wird vdpau nichts grundsätzlich ändern? Aktiviert EasyVDR für xineliboutput keinen Deinterlacer?

Von daher eine Grundsatzfrage: ist die Qualität mit vdpau tadellos hinzubekommen - oder wird man mit einer HDe oder der in regelmaessigen Abständen neu erhofften FF-DVB-S2 prinzipiell immer besser fahren?

CPU-Auslastung bei Wiedergabe von Standard DVB-T/-S Material übrigens bei max. 20% (ohne vdpau - jedenfalls hätte ich es nicht wissentlich aktiviert). Noch kein HD-Material getestet - ausser eine .mp4 über mplayer (Film Home von YouTube, läuft flüssig).

Nächster Schritt ist dann ein DVB-S2-USB-Device (gibt offenbar nur TeVii 650 und TT 3600) und vdpau. Wie es aussieht (Stichwort oben: HD Repack) darf ich dazu eh nochmal von vorne anfangen mit der Installation. Zusatz-Erschwernis: möchte die Platte nicht platt machen, soll von USB-Stick laufen (tuts beim aktuellen Stand). Bleibt spannend.

Wie ist denn generell die Empfehlung: ist EasyVDR eine gute Basis? Oder doch besser alles von Hand - auf Basis welcher Distri? Gibts irgendwo eine gute, vollständige Schritt-für-Schritt-Anleitung für sowas: VDR für DVB-S2 mit vdpau..? Ich lese hier immer wieder von einem gewissen e-Tobi - was hat es damit auf sich?

Danke für alle Hinweise!

kt1040

ehlo,

1. Man kann es ganz sicher einbauen. Voraussetzung ist dass man sich gut mit vdrconvert auskennt. Ich verwende vdrconvert zur DVD-Erstellung, aber zum Umwandeln nach xvid etc bevorzuge ich vdrrip. Warum nimmst Du nicht das? Ist nur ein zusätzliches Plugin, kostet nix

2. Das wird Dir niemand beantworten können, der nicht genau weiss was Du da hast und es selbst schon mal probiert hat. Aber entsprechend dem was ich und andere in dem verlinkten Thread (in dem von Dir verlinkten Thread) dazu schreiben: sehr unwahrscheinlich! Es ist wie gesagt eine sehr spezielle Version, die man da braucht. Es sei denn, das hätte sich mit aktuellen Versionen wieder geändert. Aber allgemein ist das Echo auf mein Posting ja nicht grade gross gewesen, das Interesse an der PSP als VDR-Filmabspuler scheint also begrenzt.
Du wirst vermutlich nicht um das Nachvollziehen meiner Anleitung rumkommen (die ja auch wiederum nur eine Zusammenfassung der Erkenntnisse anderer ist), wenn Du es nutzen willst. Auf Knopfdruck out-of-the-box installiert gibts das fürchte ich noch nicht. Aber keine Angst: alles halb so wild.

hivdr

Hallo,

ich poste das mal falls es jemand brauchen kann. Achtung: ganz rudimentärer Hack zum Eigenbedarf, in keiner Weise "schön" und mit etwas Bastelei verbunden!

Um also mit vdrrip (ein sehr nettes Plugin zum Umwandeln von Aufnahmen in xvid usw. - siehe Wiki) auch PSP-fähige Videos generiert zu bekommen, macht man folgendes:

• Grundvoraussetzung ist ein lauffähiges ffmpeg mit PSP-Unterstützung, was schon mal nicht ganz trivial ist - dazu habe ich in folgendem Thread was hinterlassen:
  http://vdrportal.de/board/thread.php?threadid=32464&sid=&hilight=psp
  Gelingt die Umwandlung auf der Kommandozeile, kann man sich an die Einbindung in vdrrip machen:
  

  
  

• Man lege ein Umwandlungs-Skript an: /usr/local/bin/psp_encode
  
  
  Code

  cd $1
  if [ -e /tmp/pspnr ]
  then
   NR=`cat /tmp/pspnr`
   NR=$(($NR + 1))
  else
   NR=10000
  fi
  echo $NR > /tmp/pspnr
  
  
  MAP=""
  CHECKSTREAM=`ffmpeg -i "$2" 2>&1 | grep mp2 | awk '{print $2}'`
  if [ "$CHECKSTREAM" = "#0.1:" ]
  then 
   MAP="-map 0:0 -map 0:1"
  fi
  if [ "$CHECKSTREAM" = "#0.2:" ]
  then 
   MAP="-map 0:0 -map 0:2"
  fi
  if [ "$CHECKSTREAM" = "#0.3:" ]
  then 
   MAP="-map 0:0 -map 0:3"
  fi
  if [ "$CHECKSTREAM" = "#0.4:" ]
  then 
   MAP="-map 0:0 -map 0:4"
  fi
  
  
  ffmpeg -i "$2" -f psp $MAP -bitexact -vcodec xvid -s 320x240 -r 29.97 -qscale 4 -acodec aac -ac 2 -ar 24000 -ab 48 -title $3 M4V$NR.MP4 >/tmp/pspencode.log 2>&1
  touch M4V${NR}_$3

  Alles anzeigen

  Man sieht: es wird ein laufender Zähler für die Filenamen in /tmp/pspnr gespeichert, und der Umwandlungsoutput landet in /tmp/pspencode.log.
  Die hässlichen checkstream-Abfragen versuchen, die richtige Audio-Spur (mp2 und nicht etwa ac3, was mein ffmpeg nicht verkraftet) zu finden. Ganz robust ist das so vermutlich aber nicht. Die genauen ffmpeg-Parameter kann man nat. bzgl. framerate etc noch variieren je nach Gusto.

  
  

• Dann wird das ganze im /usr/local/bin/queuehandler.sh von vdrrip eingebunden: in encode() direkt über "# encode in two passes":
  
  
  Code

  if [ "$vcodec" = "psp" ]
    then
      local ifile="$tempdir/temp.vdr"
      log_info  "encoding for psp: $shortname"
      /usr/local/bin/psp_encode $tempdir $ifile $name 
      return;      
    fi

  Hier auf den richtigen Pfad zum encode-Skript achten! Es wird also im Falle des "virtuellen" Video-Codec "psp" einfach die Umwandlung angestossen und dann abgebrochen. Das heisst insbesondere auch, dass keinerlei Einstellugen aus dem vdrrip-Umwandlungs-Menu hier berücksichtigt werden. Einfach auf codec "psp" stellen, der Rest ist egal (ich sagte ja schon: unschöner Hack..)

  
  

• Um schliesslich den codec "psp" angeboten zu bekommen, muss man noch eine winzige Änderung im eigentlichen vdrrip-Plugin machen: in codecs.c in Zeile 79 folgende Zeile einfügen:
  
  
  Code

  VCodecs[NumVCodecs++] = "psp";

Sicherlich in jeder Hinsicht ausbaufähig, aber bei mir läufts, und vielleicht will es ja mal jemand auch ausprobieren. Ich finde, man kann etwa Serienfolgen auf der PSP unterwegs ganz gut ansehen, für abendfüllende Spielfilme ist das eher nicht so geeignet..

hivdr

Als ich neulich das alles ausprobiert habe, war es nicht so
leicht, es hinzubekommen: um auf meiner PSP (FW 2.0) abspielbare
Videos erzeugen zu können, musste ich das genau für die PSP
gepatchte ffmpeg verwenden, aktuelle Versionen aus cvs haben
nicht geklappt! Ausserdem hat diese Version (angeblich ein
Unix-backport der Windows' PSP Video 9 zugrundeliegenden Version)
wohl als einzige auch die -title Option, um den Titel in der
MP4-Datei zu setzen.
Die Version, von der ich hier spreche, findet man in folgendem Thread:
http://www.pspvideo9.com/forums/viewtopic.php?t=98
Genauergesagt findet man zwei Links zu einer Basis, einem Patch, und
dann muss man noch wie in einem Post weiter unten beschrieben
weitere Änderungen vornehmen.

Etwas umständlich also. Das Ergebnis meiner Bemühungen
findet sich exemplarisch mal hier, ohne Gewähr!
Darin liegt auch ein _readme.txt mit configure-commandline.

Man benötigt auch faac und xvid zum Bauen, hier hat bei mir jeweils eine
aktuelle Version funktioniert.

Damit sollte dann das Enkodieren in folgender Weise ein
brauchbares Stück PSP-Video erzeugen:
ffmpeg -i <infile> -f psp -bitexact -vcodec xvid -s 320x240 -r 29.97 -qscale 4 -acodec aac -ac 2 -ar 24000 -ab 48 -title <titel> M4V00001.MP4

Wie man das ganze nun in vdrrip einbindet, um vom Sofa aus die
Umwandlung beliebiger Aufnahmen anzustossen, poste ich demnächst
im Plugins-Forum! (aber Warnung: nur ein rudimentärer Hack..)

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.

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..

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,

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

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.

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.

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.

Zitat

Original von torsten lang
Ich habe mir die 0.4.0pre1 besorgt - da ließ sich dann auch der Client wieder compilieren.

Ahm, sorry für die blöde Frage, aber: woher?
Die Homepage ist ja seit laengerem nicht mehr gepflegt, im /contrib finde ich maximal das 0.3.3-pre4 und im CVS liegt auch seit mind. zwei Monaten der gleiche Stand eines 0.3.3-irgendwas.
Gibts da eine streamdev-Infoquelle die ich noch nicht kenne?

Und (siehe auch mein Thread "streamdev im Mischbetrieb") funktioniert denn im
VDR-to-VDR die Streaming control? Meine letzte Info zu dem Thema war dass dies
im 0.3.3-cvs deaktiviert sei. Ich betreibe auf dem client 0.3.3-pre4 und da gehts
solala, wie im erwähnten Thread genauestens beschrieben.

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.

Dein Effekt ist mir so direkt nicht bekannt. Aber vielleicht hängt es zusammen mit einem der folgenden:

- In meinem aktuellen Thread hier (streamdev im Mischbetrieb) findet sich ein Link auf einen Thread wo beschrieben ist, wie man den Effekt behebt, dass beim Umschalten mit P+/- nur innerhalb eines Transponders gewechselt wird.

- Die Meldung "Kanal nicht verfügbar" bekomme ich auch nicht, nur einen schwarzen Schirm - etwa wenn der Transponder definitiv nicht zur Verfügung steht, weil auf einem anderen aufgenommen wird

- Wie im VDR-Wiki zu streamdev ganz unten beschrieben: man sollte wohl im Server-Setup auf dauerhaft "suspended" stellen - was auch immer das so ganz genau bedeutet..

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.

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!

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.

Also denn mal wieder der aktuelle Stand:

Habe die 0.3.3-pre4 (meldet sich aber mit -pre3) aus dem angegebenen
Verzeichnis im Client (1.2.5) zum Laufen gebracht.
Nicht aber im Server (1.3.23) - da kompiliert das nicht, es läuft
also nach wie vor die CVS-Version von Anfang Juli.

Folgendes funktioniert nun (teilweise):

- Das Streaming als solches: ich kann die entsprechenden
remote-channels ansehen. Gelegentlich kleine Ruckler, aber
darum gehts mir auch nicht in erster Linie.
Damit ich allerdings mit P+/- die Programme normal durchschalten
kann, musste ich eine kleine Änderung im Server machen, wie
hier erklärt:
http://www.vdr-portal.de/board/thread.php?threadid=37828&sid=

- Die Streaming Control ist als Menu vorhanden und ich kann
vorhandene remote Timer sehen. Ich kann sie auch löschen.
Allerdings kann ich sie nicht editieren! Wenn ich das mache, hat
es keinen Effekt. Angezeigt wird ausserdem der Programmplatz
wie er auf dem Server ist. Den vom Client zu nehmen lässt
eine Fehlermeldung im Log verschwinden, aber Änderungen
am Timer werden trotzdem nicht übernommen.
Ich kann neue Timer anlegen - wobei ich die Programmplätze
vom Client verwenden muss. Ich muss allerdings mühsam
alles von Hand machen, inkl. Filename, da EPG nicht
geht (siehe unten)

Garnicht klappt:

- Remote Recordings:
Nichts zu sehen - ist aber nicht notwendig, da ich ja über Filesystem
zugreife.

- EPG: da steht im Log:
ERROR: unexpected tag while reading EPG data: V 1125849900
ERROR: Streamdev: Parsing EPG data failed
Da wird dann wohl doch der Unterschied zwischen Server (1.3)
und Client (1.2) zuschlagen?

Schade, denn mit EPG könnte man schon sehr gut mit der
Gesamtsiutation leben: man könnte komfortabel Timer anlegen
und löschen (nur nicht ändern - dann halt löschen und nochmal).

Also, es geht so einiges. Nur recht rund ist es nicht. Aber wenn
1.3 und 1.2 im Mischbetrieb eigentlich nicht vorgesehen ist, muss
ich wohl noch recht zufrieden sein.

Werde, da es inzwischen um streamdev geht, evtl. auf einen
Thread im Plugin-Forum umsteigen. Danke an alle hier, und nat.
Dank an mac66 - mit Deinen Hinweisen hab ich es immerhin so
weit gebracht, dass das wichtigste im Prinzip funktioniert.

Also weiter hier:
http://vdrportal.de/board/thread.php?threadid=38575&sid=