Beiträge von Wyse

    Hi,


    Ich habe ebenfalls versucht das Plugin für Plex zu installieren. Da ich leider keinen Erfolg hatte habe ich mir den Sourcecode etwas angeschaut und festgestellt dass das Plugin zuerst die Kanalgruppen holt.


    Wenn man nun wie ich keine Gruppen hat funktionert das ganze natürlich nicht. Es sollte als im aktuellen Zustand mindestens eine Gruppe vorhanden sein.



    Nur als Hinweis falls noch jemand drüber stolpert.



    Ansonsten Vielen Dank für das Plugin.

    Hi,


    Ich hole mal den Thread wieder hoch da ich aktuell Probleme mit aktualisieren der Episoden habe.


    Ich bekomme bei einem manuellen Aufruf mit:
    svdrpsend-ng -d eplists.constabel.net -p 2006 -c -e UTF8 -o ./ TGET newer than 25 hours


    folgenden Fehler:
    Unbekannte Zeile: Too many connections (max 20). Please try again later.


    Wenn ich auf die Seite eplists seite gehe steht da statt der sonst aktuell veränderten Serien auch nur eine Fehler:


    Error: Failed to load processor NewsFlashNo macro or processor named 'NewsFlash' found


    Hat jemand etwas mitbekommen ob es aktuell ein Problem mit der Seite bzw. dem Service gibt?




    Wyse

    Ok. Das ist natürlich in den Größenregionen in denen ich mich bewege eher ungünstig. Da aber laufend Aufnahmen dazu kommen wird das vom Prinzip her noch langsamer werden. Gerade da LSTR oft zu einem timeout führt... warum auch immer. Gemountet ist das ganze übrigens via NFS über Gigabit LAN.


    Jemand eine Idee wie ich dem etwas entgegen wirken könnte?


    btw:
    Aktuell habe ich um die 3000 Aufnahmen und zusätzlich nochmal um die 600GB avis auf dem NAS.

    Aha das erklärt das ganze.


    Ich habe in einem extra Thread schon mal nachgefragt warum das aktualisieren der Aufnahmen so langsam geht. Da es sich hierbei im Endeffekt um die selbe Funktion handelt erklärt sich das Verhalten des Plugins auch.


    Ich habe ca. 5 TB an Aufnahmen auf meinem NAS. Die meisten sind Serien. Im NAS werkeln 5x 2TB 5400er Platten die natürlich nicht die schnellsten sind. Außerdem gehen die Platten in Standby wenn es keine Zugriffe gibt.


    Ich habe das eben mal reproduziert


    1. Der erste Aufruf von svdrpsend LSTR gab einen timeout. Die Platten mussten ja erst noch hoch gefahren werden.
    2. svdrpsend LSTR direkt im Anschluss gab ein Teil der Liste wurde jedoch auch mit einem timeout beendet. Die Platten waren wohl noch nicht fertig.
    3. Wieder svdrpsend LSTR im Anschluss hat dann das erwartete Ergebnis gebracht. Dauert allerdings auch um die 10 Sekunden. Damit sollte ich dann auf die 15 Sekunden die ich oben beschrieben habe kommen.


    Ich habe Interesse halber den Befehl 20x hintereinander ausgeführt und so jedes 10te mal hatte ich wieder einen timeout. Aber das nur btw.


    Ich vermute das LSTR ist dazu du um die Aufnahme für das plugin aktuell zu halten? Im Prinzip funktioniert das aber immer noch besser wie das lokale Schneiden. Hier wird mein System bei großen HD Aufnahmen zum Teil Minuten blockiert.


    Edit:
    Vom client aus erhöht sich die Zeit nochmal um ca. 5 Sekunden. Zusammen ergibt das die Summe von oben.

    Speziell zum testen passiert zu diesem Zeitpunkt auf dem Server nichts. Also weder Aufnahmen nocht Suchtimer noch Streamdev. Er langweilt vor sich hin.


    Habe den Schnitt von einem Client mit eigener TV-Karte gestartet. Eben weil die Schnittstelle ja immer nur einen Client bedienen kann sollte doch nach dem Connect der ja Erfolgreich ist nichts dazwischen funken. Ich gehe also davon aus dass es 20 Sekunden benötigt die entsprechenden Anweisungen vom Client auf den Server zu bekommen um dort den Schnitt zu starten. Das scheint mir doch sehr lange.

    Hi,


    Beim Aufbau meines Headless yaVDR bin ich noch eine etwas unschöne Geschichte gestossen. Nachdem ich svdrpservice, remotetimers und remoteosd auf den clients konfiguriert hatte hat alles soweit gut funktioniert. Einzig das Serverseitige Schneiden macht mir Probleme.


    Ich habe die Aufzeichnung auf dem Client geöffnet und die marks entsprechend gesetzt. Danach habe ich mit Editieren (rot) und Schneiden (grün) das externe Schneiden gestartet. Im log des headless Servers konnte man sehen dass eine svdrp Verbindung aufgebaut wurde. Nach 10 Sekunden (command timeout) hatte ich auf dem headless Server ein Fehler.


    Code
    ERROR (svdrp.c,433): Datenübergabe unterbrochen (broken pipe)


    Auf dem client:

    Code
    Apr  8 12:43:38 yavdr-wz vdr: [6326] loading /srv/vdr/video.00/Serien/Fantasy/EUReKA_-_Die_geheime_Stadt/Season_05/05~01_Die_Zeitverschiebung/2013-03-13.20.10.72-0.rec//marks
    Apr  8 12:43:39 yavdr-wz vdr: [6326] SvdrpService: connected to 192.168.1.5:6419
    Apr  8 12:43:49 yavdr-wz vdr: [6326] svdrpservice: timeout waiting for reply from 192.168.1.5
    Apr  8 12:43:49 yavdr-wz vdr: [6326] ERROR: Lost SVDRP connection - unable to start remote cutter
    Apr  8 12:43:51 yavdr-wz vdr: [6326] svdrpservice: unable to send command to 192.168.1.5. Socket is closed


    Gehe ich nun her und stelle in den Optionen des SvdrpService Plugins Command Timeout auf 30 Sekunden ein. Funktioniert das ganze. Im Schnitt dauert es 15-20 Sekunden bis das Schneiden auf dem Server beginnt.


    Code
    Apr  8 12:47:02 yavdr-hl vdr: [2849] connect from 192.168.1.6, port 49345 - accepted
    Apr  8 12:47:16 yavdr-hl vdr: [2849] loading /srv/vdr/video.00/Serien/Fantasy/EUReKA_-_Die_geheime_Stadt/Season_05/05~01_Die_Zeitverschiebung/2013-03-13.20.10.72-0.rec//marks


    Ist diese Zeit normal? Kann mir das kaum vorstellen. Es ist übrigens egal ob ich eine HD Aufnahme über 3 Stunden schneiden möchte oder eine SD Aufnahme von 30 Minuten. Die Zeit liegt immer zwischen 15-20 Sekunden bis das Schneiden gestartet wird.

    Da ich vor kurzem auch vor dem Problem stand ein OSD eines headless Servers nutzen zu können hier ein paar Tipps.


    Zur Integration in einen VDR Client eignet sich meiner Meinung nach die Kombination aus svdrposd auf dem Server und auf dem Client remoteosd optimal. Dazu gibt es dann noch für den Client passend epgsync und remotetimers für EPG und Timer auf dem Client. Dank der guten Webseite sollte eine Installation und Inbetriebnahme kein Problem sein.


    In der Console habe ich mit dem Control Plugin zwar gute Erfahrungen was die Nutzbarkeit betrifft gemacht. Das Problem ist zumindest auf meinen VDRs habe ich eine CPU Auslastung von 100% nach dem beenden der telnet Sitzung. Dies ist auch ein bekanntes Problem. Das bedeutet nach dem nutzen des Control Plugins ist ein Neustart des VDRs angesagt. Nicht optimal aber immerhin einfach und schnell. Soweit ich mitbekommen habe funktioniert das Control Plugin allerdings nicht mehr mit VDR 2.0.


    Das Remote Plugin hat sich bei mir auf der Console als bessere Lösung herausgestellt. Nach dem Installieren habe ich wie in dem oben verlinken Thread die /etc/vdr/plugins/plugin.remote.conf angepasst.

    Code
    # -i autodetect # unbedingt auskommentieren/löschen, sonst gibt es lustige Interaktionen mit eventlircd ...
    -p tcp:3333


    Danach noch die /etc/vdr/remote.conf wie in dem Thread beschrieben angepasst. Einziger Unterschied zu dem dort verlinkten Mapping war die Änderung der Menu Taste auf m und der Back Taste auf Backspace. Daran hatte ich mich schon gewöhnt.


    Mapping:


    Nach einem Neustart des VDR kannst du via telnet unter Linux entsprechend eine Verbindung aufbauen.

    Code
    telnet localhost 3333


    Danach lässt sich der headless Server via OSD gut bedienen wenn auch etwas langsamer als mit dem Cotrol Plguin (Fällt vor allem bei langen Listen wie beim Mapping von xmltv2vdr auf). Die Sitzung beenden geht übrigens mit STRG und der Plustaste (+). Die Plustaste auf dem Ziffernblock funktioniert nicht. Das liegt wohl daran das das Plus auf der US Tastatur ein ] ist was die Standard Escape Kombination von telnet ist. Mit Putty funktioniert das ganze natürlich auch nur bei den Einstellungen unter Keyboard Linux wählen und das encoding unter Translation auf UTF-8 ändern.


    Wyse

    Ich hänge mich einfach hier nochmal mit dran. Habe dank dem verlinkten Thread mal ein bisschen an einer XSL für timefor.tv gebastelt.


    Im Prinzip ist in der Datei nur eine Map in der die von timefor.tv vergebenen IDs auf die von xmltv2vdr genutzten Namen mappt. Das XSL ersetzt nun das Attribut IDs von timefor.tv im Channel Tag mit den gemappten. Im zweiten Schrit werden noch die Programmdaten aktualisiert. Es wird im Tag programme das Attribut channel von der timefor.tv id auf die xmltv2vdr id gemappt. Ich habe die meisten deutshcen Sender die auf timefor.tv verfügbar sind bereits in die Map aufgenommen. Wenn welche fehlen kann die Map einfach um einen Eintrag erweitert werden.


    <channel id="www.timefor.tv/tv/IDDESKANALS" xmltv2vdr="XMLTV2VDRKANAL"/>
    z.B.:
    <channel id="www.timefor.tv/tv/162" xmltv2vdr="ard.de"/>


    Jetzt bräuchte man nur noch ein Script dass täglich die Datei herunterlädt via xsltproc transformiert und in das entsprechende Verzeichnis legt. Ich bin mir noch nicht ganz schlüssig ob ich das durch einen cronjob erledigen lassen soll oder direkt vom Plugin über das timefortv Script dass aufgerufen wird.


    Mit cronjob wäre dann noch ein summy Script notwendig dass genau wie der Grabber unter /var/lib/epgsources/ heist und praktisch nur exit 0 zurückgibt. Dann muss sichergestellt werden das der Cronjob die Arbeit übernimmt.


    Prinzipiell ist es aber immer die selbe vorgehensweise.


    1. Herunterladen der aktuellen TV-Daten von timefor.tv (wget http://timefor.tv/xmltv/PIN -O /tmp/timefortv.xml)
    2. Transformieren der TV-Daten mit dem angehängten xsl via xsltproc (xsltproc /var/lib/epgsources/tft2xmltv2vdr.xsl /tmp/timefortv.xml > /var/lib/epgsources/timefortv.xmltv)
    3. ggf. Eigentümer und Gruppe der neuen Datei auf vdr ändern (chown vdr:vdr /var/lib/epgsources/timefortv.xmltv)
    4. Update der EPG Daten starten (svdrpsend plug xmltv2vdr updt)


    Das Update kann man sich natürlich sparen wenn man das Script für den Grabber nutzt. Nachdem das Script mit exit 0 beendet wird wird automatisch ein Update angestartet.



    Falls ich etwas dabei vergessen habe bitte ich um Feedback.

    Hi,


    Es gab dazu hier schon mal einen Thread den ich leider im Moment nicht finde. Das Problem liegt dan der /etc/init/first-vdr-start.conf. Was auch immer das Script macht mag nicht funktionieren wenn keine nvidia Grafikkarte im System vorhanden ist. Ich habe dann testweise das Script in mein home Verzeichnis verschoben und siehe da der VDR-Backend startet.


    Ob das nun gut ist oder nicht kann ich noch nicht sagen da ich für den headless Server auch noch am testen bin.

    Auch das OSD reagiert etwas zäh. Ich werde testen ob das ohne extrecmenu etwas schneller wird.


    Ich beziehe mich hier aber hauptsächlich auf die Funktion Aufnahmeliste aktualisieren. Lässt sich auch einfach nachvollziehen. Wenn ich das ganze manuell anstarte dauert es mehrere Minuten bis der komplette Inhalt aktualisiert wurde.


    Angebunden ist das NAS via gigabit LAN mit zwei bzw. drei Gigabit Switches. Die reinen übertragunsraten liegen beim kopieren auf eine SSD via NFS > 80MB/s.

    Hallo,


    Inzischen sind auf meinem NAS ca. 4 TB an Aufnahmen zusammen gekommen. Davon sehr viele Serien mit entsprechend vielen Dateien. Die Verbindung zum NAS wird via NFS gemacht und direkt auf /srv/vdr/video.00 gemountet. Alle Systeme (siehe Singnatur) greifen auf diese Aufnahmen zu. Die /etc/exports der Installationen wurden entsprechend angepasst dass Sie nicht nochmal den kompletten Inhalt des Aufnahmeverzeichnisses bereit stellen.


    Nach dem starten wird die Aufnahmeliste aktualisiert. Dies dauert bei mir mehrere Minuten und extrem nervig wenn man den VDR anschaltet um eine Aufnahme zu schauen. Hat jemand einen Tipp wie ich das beschleunigen könnte?

    Hallo,


    Gibt es in yaVDR einen Mechanismus der automatisch eine TV-Karte verschlüsselten Kanälen zuordnet?


    Folgendes Szenario. Ich habe 2x TT 1600 PCI Karten in meinem VDR und wollte nun auf drei erweitern. Mangels Platz im Gehäuse habe ich mir eine Sundtek SkyTV Ultimate gekauft. Sobald ich die Karte installiert habe werden alle FTA Sender auf den 1600ern angezeigt während verschlüsselte Kanäle über den Stick laufen. Testweise habe ich meine TT 3600 auch an den VDR im Wohnzimmer gehängt und damit habe ich den gleichen Effekt. Wenn ich eine Aufnahme auf dem USB Adapter sarte und dann die durch die Kanäle zappe komme ich wieder auf die TT 1600 was natürlich klar ist.


    Das umschalten von einem FTA zu einem Sky Kanal dauert sehr lange was sicher daran liegt.


    Noch etwas Off Topic.
    Wie deaktiviere ich die IR Unterstützung beim Sundtek. Die Version mit editieren von /etc/sundtek.conf (ir_disabled=1) habe ich ausgiebig getestet. Allerdings scheint das nicht zuverlässig zu funktionieren. Die Harmony funktioniert mal dann wieder nicht. Wenn nicht muss ich im WFE einmal dire LIRC konfiguration speichern und der atric nimmt die Befehel wieder entgegen.



    Ciao


    Wyse

    Hi,


    Ich habe mit Seahawks ppa sowohl auf einem Android Stick wie auch auf dem Pi mit RaspBMC keine Probleme. Allerdings ist die Qualität von Live-TV mit HD bei mir noch grenzwertig. Ich aver auch noch nichts auf dem Pi konfiguriert. Auch das XBMC Plugin für das NHL Game Center funktioniert auf dem XBMC von Seakhawk... zumindest genauso gut/schlecht wie auf jedem anderen System auf dem ich testen konnte.


    Ich habe mich nur an die Anweisungen aus Seahawks Thread gehalten und danach von https://github.com/pipelka/xbmc-addon-xvdr/wiki das Raspberry Pi AddOn heruntergeladen und im RaspBMC installiert und konfiguriert. Hat soweit alles ohne Probleme funktioniert. Die Umschaltzeiten sind aber eher suboptimal im Vergleich zu Streamdev vdr<->vdr.

    Ich denke das muss zwangsläufig etwas mit der Kombination AV-Receiver zu tun haben. Ich habe hier im Haus 4 yaVDR am laufen. Davon 3 mit eigenen TV-Karten. Zwei mit Onboard Grafik und zwei mit Grafikkarte (210/220). Alle Rechner haben identische Konfigurationen.


    Mit softhddevice habe ich an den 3 VDR ohne AV Receiver noch nicht eimal ein problem gehabt. Am vierten VDR habe ich die selben Probleme die hier schon reichlich beschrieben wurden. Alle Änderungen in den entsprechenden confs haben nicht zum Erfolg geführt.


    Übringens geht der TON problemlos wenn man einen anderen Frontend wählt. Ich habe ausgiebeig mit xine, xineliboutput und XBMC Frodo getestet keine Probleme gehabt. Da ich das Problem auch erst seit ein paar Wochen habe liegt die Vermutung nahe dass es mit einem upgrade aufgetaucht ist. Aber das können uns sicher nur die yaVDR Götter erklären. Um den Haussegen hier zu wahren lass ich erst mal xineliboutput im Wohnzimmer laufen.

    Hallo,


    Ich habe eine X10 Fernbedienung. Die zweite von Links in der ersten Reihe. Beim einstellen der Tasten sind mir ein paar Kleinigkeiten aufgefallen.


    In der Standard remote.conf die laut Doku ja nicht verändert werden sollte fehlt der Key KEY_TV in der remote.conf aus diesem Grund kann die Taste "Live TV" auch nie eine Funktion in den VDR Frotends übernehmen. In XBMC wird die Taste allerdings genutzt. Wenn man entspechend hergeht und die rc-medion-x10 anpasst auf einen anderen Key der nutzbar im VDR ist anpasst muss man entsprechend die lircmap.xml ändern.


    Es wäre hier wohl von vorteil wenn statt eines KEY_PROGx der KEY_TV verwendet würde. So könnte man sich die Konfiguration der Taste KEY_TV anpassen wie man möchte ohne die remote.conf oder lircmap.xml anzupassen.


    Da ich XBMC nicht nutze habe ich die Taste entsperechend auf KEY_PROG2 geändert und sie flexibel einsetzen zu können.


    Da die Version der /lib/udev/rc_keymaps/rc-medion-x10 ootb nicht zu der oben genannten Version passt hier noch meine geänderte Version:

    Code
    # table rc-medion-x10, type:other0x0000 = KEY_MUTE0x0002 = KEY_POWER20x0004 = KEY_PROG30x0005 = KEY_IMAGES0x0006 = KEY_MODE0x0008 = KEY_VOLUMEDOWN0x0009 = KEY_VOLUMEUP0x000b = KEY_CHANNELUP0x000c = KEY_CHANNELDOWN0x000d = KEY_10x000e = KEY_20x000f = KEY_30x0010 = KEY_40x0011 = KEY_50x0012 = KEY_60x0013 = KEY_70x0014 = KEY_80x0015 = KEY_90x0016 = KEY_TEXT0x0017 = KEY_00x0018 = KEY_FN0x001a = KEY_UP0x001b = KEY_MENU0x001c = KEY_PROG40x001d = KEY_LEFT0x001e = KEY_OK0x001f = KEY_RIGHT0x0020 = KEY_ESC0x0021 = KEY_BACK0x0022 = KEY_DOWN0x0023 = KEY_NEXT0x0024 = KEY_REWIND0x0025 = KEY_PLAY0x0026 = KEY_FASTFORWARD0x0027 = KEY_RECORD0x0028 = KEY_STOP0x0029 = KEY_PAUSE0x002d = KEY_VIDEO0x002f = KEY_INFO0x0031 = KEY_EPG0x0032 = KEY_RED0x0033 = KEY_GREEN0x0034 = KEY_YELLOW0x0035 = KEY_BLUE0x0037 = KEY_SETUP0x0038 = KEY_SCREEN


    In Verbindung mit meiner bisher nur etwas veränderten /etc/vdr/keymacros.conf


    Code
    # Remote control key macros for VDRRed  	RecordingsGreen	ChannelsYellow   SetupBlue 	TimersUser0	@osdteletextUser9	@softhddevice Blue 2 5 # toggle autocrop



    Habe ich alles bis auf die Untertitel und Befehle (brauche ich nicht) abgedeckt. Falls man diese trotzdem braucht kann man sie einfach in der keymacros.conf auf eine der freien (User3, User4, User8, User7, User6 ) Tasten legen. Interessanterweise scheinenen die Keys KEY_PROG1 und KEY_PROG2 für funktionen reserviert zu sein die ich nicht in der keymacros.conf und in der remote.conf finden konnte. Wenn ich KEY_PROG1 mappe wird der Frontend deatched wenn ich KEY_PROG2 mappe wird XBMC gestartet.



    Hier noch die Verteilung die Codes über die Fernbedienung insgesamt 46 Tasten:

    Code
    1c    	 18    	0205    	 06    	3104    	 2d    	1632    	 34    	0935    	 33           1a    	 	08 1d   1e     1f  	00      22    	     0b0d     0e     0f     0c10     11     12     13     14     15     2037     17     38     2f   	1b    	 24     25     26     2921     23     28     27


    Ich hoffe ihr erkennt die Tasten so.



    Hier noch eine Tabelle die den Zusammenhang vom Code bis zur Taste darstellt:

    Code
    Code      HexaCode   	Rc-medion-x10   remote.conf      keymacros.conf00   	 0x0000    	 KEY_MUTE   	 LIRC.Mute02   	 0x0002    	 KEY_POWER2      LIRC.Power     04   	 0x0004    	 KEY_PROG3   	LIRC.User3     05   	 0x0005    	 KEY_IMAGES      LIRC.User7     06   	 0x0006    	 KEY_MODE   	 LIRC.Audio     08   	 0x0008    	 KEY_VOLUMEDOWN  LIRC.Volume-     09   	 0x0009    	 KEY_VOLUMEUP    LIRC.Volume+     0b   	 0x000b    	 KEY_CHANNELUP   LIRC.Channel+     0c   	 0x000c    	 KEY_CHANNELDOWN LIRC.Channel-     0d   	 0x000d    	 KEY_1    	   LIRC.1     0e   	 0x000e    	 KEY_2    	   LIRC.20f   	 0x000f     	KEY_3       	LIRC.310    	0x0010    	 KEY_4    	   LIRC.4     11    	0x0011    	 KEY_5    	   LIRC.5     12    	0x0012    	 KEY_6    	   LIRC.6     13    	0x0013    	 KEY_7    	   LIRC.7     14    	0x0014    	 KEY_8    	   LIRC.8     15    	0x0015    	 KEY_9    	   LIRC.9     16    	0x0016    	 KEY_TEXT   	 LIRC.User0   	   @osdteletext17    	0x0017    	 KEY_0   		LIRC.0     18    	0x0018    	 KEY_FN   	   LIRC.User8     1a    	0x001a    	 KEY_UP   	   LIRC.Up     1b    	0x001b    	 KEY_MENU   	 LIRC.Menu     1c    	0x001c    	 KEY_PROG4   	LIRC.User4     1d    	0x001d    	 KEY_LEFT   	 LIRC.Left     1e    	0x001e    	 KEY_OK   	   LIRC.Ok     1f    	0x001f    	 KEY_RIGHT   	LIRC.Right     20    	0x0020    	 KEY_ESC   	  LIRC.Back     21    	0x0021    	 KEY_BACK   	 LIRC.Prev     22    	0x0022    	 KEY_DOWN   	 LIRC.Down     23    	0x0023    	 KEY_NEXT   	 LIRC.Next     24    	0x0024    	 KEY_REWIND      LIRC.FastRew     25    	0x0025    	 KEY_PLAY   	 LIRC.Play     26    	0x0026    	 KEY_FASTFORWARD LIRC.FastFwd     27    	0x0027    	 KEY_RECORD      LIRC.Record     28    	0x0028    	 KEY_STOP   	 LIRC.Stop     29    	0x0029    	 KEY_PAUSE   	LIRC.Pause     2d    	0x002d    	 KEY_VIDEO   	LIRC.User6     2f    	0x002f    	 KEY_INFO   	 LIRC.Info     31    	0x0031    	 KEY_EPG   	  LIRC.Schedule     32    	0x0032    	 KEY_RED   	  LIRC.Red   	  	Recordings33    	0x0033    	 KEY_GREEN   	LIRC.Green   	    Channels34    	0x0034    	 KEY_YELLOW      LIRC.Yellow   	   Setup35    	0x0035    	 KEY_BLUE   	 LIRC.Blue            Timers37    	0x0037    	 KEY_SETUP   	LIRC.Setup     38    	0x0038    	 KEY_SCREEN      LIRC.User9   	    @softhddevice BLUE 2 5