Posts by Telperiar

Welche XBMC Version ist eigentlich in yaVDR 0.3? Denn für mich klingt das nach einem Versionsproblem. Der Repo Installer ist für XBMC 9.0, während der Skin den du zu installieren versuchst für 10.0 sein könnte.

Bei mir (XBMC 10) heisst der Ordner für Aeon "skin.aeon" und enthält die obligatorische "description.xml" welche er zum finden des Addons braucht.

Joe_D Danke, das Script ist für VDR 1.6 oder? Mal recherchieren ob wie sich der Index da zu 1.7 geändert hat.

Copperhead Und wo ist das Problem? VDR ist doch keine "Blackbox", gerade in Verbindung mit anderen Programmen wird es erst richtig stark.

Existiert eine Möglickeit (oder ist sie geplant) um die Marken von markad in ProjectX zu übernehmen? Wenn ich eine Aufnahme schneide, dann eigentlich nur wenn ich sie behalten will. Das lässt sich mit ProjectX deutlich komfortabler machen als über die FB. Ausserdem kann man dort Vorlauf/Nachlauf und pausenlose Übergänge in Doppelfolgen besser erkennen.

Nicht bei Audio soweit ich weiß. Ich kann zur RT2860 wenig sagen ich habe so eine Karte nicht. Kommt scheinbar ja auch stark darauf an welchen Kernel man einsetzt. Zu Ubuntu findet sich z.B. sowas hier:

http://ubuntuforums.org/showthread.php?t=1476007

Da werden Parameter zum WPA_SUPPLICANT geändert, vielleicht hilft dir das. Und sonst fand ich noch das hier:

http://rt2x00.serialmonkey.com/phpBB2/

Ich denke mal die haben da mehr Ahnung von der Karte als wir

Das klingt mri schwer nach einem Problem mit deinem WLAN, das scheint immer mal wieder neu zu verbinden. Sucht man nach "rt_ioctl_giwscan" findet man einige Bug-Reports im Ubuntu-Tracker zum rt2860/rt2870 Treiber - aber ich weiß natürlich nicht welche Karte/Stick du nutzt.

Das du bei Audio Aussetzer, bei Video aber nicht hast könnte schlicht daran liegen das bei Video deutlich mehr Puffer im Spiel ist. Die paar Sekunden reconnect überspielt es wohl einfach.

Ich denke nicht das XBMC das kann. Ist vielleicht auch der falsche Ansatz. Zahlreiche Programme (z.B. gwenview unter Linux) können JPEGs verlustfrei um 90° drehen. Wenn du damit einmal durch deine Sammlung gehst hast du das Problem erschlagen und musst dich in XBMC nicht mehr um die Ausrichtung kümmern.

Bevor die Gefühle hochkochen, GDA ging es darum das der OP über DISEqC und Channelscan redet, und sich dein Thema um Probleme beim Kompilieren dreht. Da hätte ein neuer Thread nicht weh getan, und dem OP zuliebe wäre ein Split des Threads angemessen.

Du hast zwar angegeben nach welchem HowTo du vorgegangen bist, aber dummerweise vergessen das Problem zu beschreiben. Wir können ja nicht riechen an welcher Stelle configure bei dir aussteigt. Darum erstmal zwei empfehlungen. Die erste ist, statt den Master des GIT-Repo auszuchecken, nimm lieber den Dharma-Branch. Am einfachsten mit

sudo git clone -b Dharma https://github.com/opdenkamp/xbmc.git

Dann mache erst mal:

sudo apt-get build-dep xbmc

Wenn Configure dannach immer noch streikt poste bitte die letzten Zeilen der Ausgabe.

Mit Dharma kam ja bekanntlich die Websteuerung über JSON raus. Dazu gibt es bereits die ersten Interfaces, mein persönlicher Favorit ist AWX. Logischerweise findet PVR im Interface keinen Platz, was es unmöglich macht damit die Sender zu wechseln.

Als Lösung kann man einfach eine neue Video-Quelle in XBMC anlegen, die aber Manuell eingegeben werden muß. Die Adresse dafür ist:

pvr://channels/tv/all/

So eingerichtet finden sich die Sender unter "Videodateien", sind genau so benannt wie gewohnt. Auch für die Aufnahmen klappt das, hier heisst die Quelle z.B.:

pvr://recordings/client_0001/

Diese muß man aber nicht händisch eingeben. Es reicht bei den Quellen auf "Suchen" zu gehen "TV Aufnahmen" zu selektieren und den gewünschten Client auszuwählen.

Diese Art des direkten Zugriffs auf den PVR ist auch hilfreich wenn der Skin der Wahl noch keine Unterstützung dafür hat. Natürlich bekommt man auf diesem Weg keinen Zugriff auf EPG oder Timer.

Quote

Ich für meinen Teil benutze die kombi headless VDR und XBMC auf Atom/ION
mit XBMC via VNSI nun schon länger erfolgreich zum pseudo-Timeshifting
des Tatorts, indem ich das Aufnahmeverzeichnis unter VIDEO einhänge.

Das geht auch Komfortabler, du kannst PVR-Aufnahmen auch als echte Quelle einbinden, z.B.:
pvr://recordings/client_0001/
Das ist dann die selbe Darstellung wie im Live-TV / Aufnahmen Bereich, und musst dich nicht mit TS-Dateien befassen.

Den pvr-testing2 branch gibt es nicht mehr. Aktuell ist opdenkamp, und da interessiert ...

https://github.com/opdenkamp/xbmc.git

Wobei du beim auschecken den Dharma Branch bevorzugen solltest, weil der Master beim PVR-Teil gerade Großbaustelle ist und eher schlecht als recht funktioniert.

Also für mich ist vdr die stabilere Wahl, gerade mit meinem eher schlechten DVB-T Empfang kommt vdr deutlich besser zurecht als tvheadend.

Ich mache immer wieder ein pull aus dem neuen git Repo, und da vergeht eigentlich kaum ein Tag ohne Änderungen am PVR Teil. Bin wirklich schwer beeindruckt, und daher ein dickes Lob an die Devs.

Die Einstellungen habe ich auch schon rauf und runter ausprobiert. Leider ändert das gar nichts, und auch die Logs bieten keinen Ansatzpunkt.

Ist es nicht generell ein schlechter Ansatz Aufnahmen auf Basis der Dateien zu behandeln statt wie herkömmlichen Stream? Nicht nur wegen der Doppelkonfiguration. Ich habe häufig Aufnahmen mit kleinen Übertragungsfehlern. XBMC stolpert dann regelmäßig beim Vorspulen darüber und bricht einfach die Wiedergabe ab. VDR ist da Schmerzfrei, schließlich ist es darauf ausgelegt.

Ist zwar mehr XBMC als VDR, aber egal.

Du musst unter Einstellungen->Skin-Optionen-> Add-On Tastenkürzel die Option Video-OSD / Aktiviere Untertitel-Download einschalten. Dann darunter bei "Pfad zum Untertitel Script" den Wert "script.xbmc.subtitles" eintragen. Danach findest du es im Video OSD.

Gibts zu diesem Problem eigentlich schon eine Lösung? Das wird ja in einigen Threads immer wieder angesprochen, nur nie bis zu einer Lösung weitergeführt. Eine Änderung des Aufnahme-Ordners ändert ja offensichtlich nichts.

Interessant. Ich habe den Eindruck als würde der Audiopuffer leer laufen. Wobei ich keine Ahnung habe wie der bei einer Echtzeit-Übertragung leer laufen kann. Einstellungsmöglichkeiten gibt es ja leider keine.

Ich habe seit längerem den Effekt das in XBMC der Ton bei Live-Übertragung stottert. Bei Aufnahmen tritt es nicht auf.

XBMC: r32595 (Wobei das auch in deutlich älteren Builds auftratt)
Backend: VNSI (vdrdevel-plugin-vnsiserver 0.01 aus etobis Quellen )
VDR-Server: 1.7.15

Neben dem Stottern im Ton füllt sich das Log mit folgenden Zeilen:

11:02:24 T:2799696784 M:1347256320 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:02:25 T:2828008336 M:1347112960 WARNING: Previous line repeats 3 times.
11:02:25 T:2828008336 M:1347112960   DEBUG: CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/18.pvr)
11:02:25 T:2799696784 M:1347112960 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:02:26 T:2828008336 M:1347366912 WARNING: Previous line repeats 8 times.
11:02:26 T:2828008336 M:1347366912   DEBUG: CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/18.pvr)
11:02:26 T:2799696784 M:1347366912 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:02:27 T:2828008336 M:1347112960 WARNING: Previous line repeats 10 times.
11:02:27 T:2828008336 M:1347112960   DEBUG: CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/18.pvr)
11:02:27 T:2799696784 M:1347239936 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:02:28 T:2828008336 M:1346985984 WARNING: Previous line repeats 9 times.
11:02:28 T:2828008336 M:1346985984   DEBUG: CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/18.pvr)
11:02:28 T:2799696784 M:1347112960 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:02:29 T:2828008336 M:1347244032 WARNING: Previous line repeats 9 times.
11:02:29 T:2828008336 M:1347244032   DEBUG: CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/18.pvr)
11:02:29 T:2799696784 M:1347244032 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available
11:02:30 T:2828008336 M:1346965504 WARNING: Previous line repeats 9 times.
11:02:30 T:2828008336 M:1346965504   DEBUG: CGUIInfoManager::SetCurrentMovie(pvr://channels/tv/all/18.pvr)
11:02:30 T:2799696784 M:1347092480 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available

Es gibt keine dropped Frames und die CPU läuft fast im Leerlauf auch kein IOWait. Jegliche "Konserve" spielt das Gerät einwandfrei, nur beim Live-TV stottert es. Manchmal hilft ein Senderwechsel, aber nicht immer. Am Empfang kann es auch nicht liegen, zeichne ich eine stotternde Sendung auf ist der Ton einwandfrei.

Statt mit dem Rasenmäher alles zu killen dürfte es locker reichen nur die folgende Datei zu löschen:

~/.xbmc/userdata/guisettings.xml

Den Einwand von INUB finde ich berechtigt. Gerade bei DVB-T kann es gerne mal Vorkommen das ein Sender auf einen anderen Platz "springt". Da bringt die Sperre der Sendernamen eher Chaos. Würde die Software bei der Logosuche verbotene Zeichen gegen "_" ersetzen, wäre das ein sinnvolles Verhalten welches man nachvollziehen könnte.

Ein weiteres wäre bei Sendeplätzen bei denen sich der Name ändert ein passendes neues Logo zu suchen oder wenigestens das alte rauszuschmeißen. Ich hatte hier nach einem stillen Wechsel einige Zeit "BibelTV" (würg) mit dem Logo von Tele5. Keine große Sache, aber es verwirrt für einige Zeit.

Von den gemeldeten Problemen auf die Stabilität zu schließen finde ich recht abenteuerlich. Wird ja völlig der Verbreitungsgrad ignoriert. Nach der Logik müsste RHEL ja die perfekte Wahl sein.

Im Grunde dürfte es relativ egal sein welche Geschmacksrichtung von Linux man nimmt, solange man es Installiert bekommt. Denn im Grunde sind doch nur Kernel und X-Server von Bedeutung, und die sind beide extrem Stabil. Wenn XBMC es nicht ist, dann liegt der Fehler garantiert nicht in der Distro.

Zu Virtualbox wäre vielleicht noch zu erwähnen das es Snapshots beherrscht. Also vor der Einspielung von XBMC einen Snapshot machen, und gegebenenfalls zurückspielen. Das geht deutlich schneller als das ganze Image zu kopieren und braucht auch deutlich weniger Platz.