[testing]Ton nach Wechsel von XBMC zu VDR weg

Ich habe das selbe Verhalten wie Boostar.

Ich vermute das der Stop des vdr-frontend nicht klappt und deshalb auch kein deta durchgeführt wird.

Eigentlich müsste doch die Bildausgabe vom VDR beendet werden wenn man "stop vdr-frontend" ausführt, bei mir läuft aber alles wie gehabt weiter im Logfile /var/log/upstart/vdr-frontend steht folgendes

wait-for-job-state stop/waiting
wait-for-job-state stop/waiting
wait-for-job-state stop/waiting
Error org.freedesktop.DBus.Error.InvalidArgs: Type of message, `(s)', does not match expected type `(ss)'
Error org.freedesktop.DBus.Error.InvalidArgs: Type of message, `(s)', does not match expected type `(ss)'

johns
Die Meldungen welche Du in Deinem Log hast tauchen bei mir nur auf wenn ich wie BooStar

stop vdr
start xbmc
stop xbmc
start vdr

durchführe, allerdings gibt es keine Meldungen vom softhddevice.
Der Loglevel des VDR ist 3 da ich im YaVDR testing bin. Nach den 4 Befehlen habe ich auch wieder Ton, allerdings hat diese Vorgehenseweise gleich zwei Nebenwirkungen:

• Live TV in XBMC geht nicht
• Mögliche Aufnahmen des VDRs werden nicht durchgeführt da der VDR nicht gestartet ist.

NACHTRAG:
Auf einem anderen VDR der ebenfalls eine NVIDIA 610 als Ausgabe Device hat schaltet sich der Ton des VDRs gar nicht ab und läuft während dem Start vom XBMC weiter.
Der einzige Unterschied ist die gewählte Audio Ausgabe, beim ersten ist es "HDMI Passthrough" und bei letzterem "Ausgabe an allen Geräten".

Quote from Frodo

Error org.freedesktop.DBus.Error.InvalidArgs: Type of message, `(s)', does not match expected type `(ss)'
Error org.freedesktop.DBus.Error.InvalidArgs: Type of message, `(s)', does not match expected type `(ss)'

Dann bist du nicht komplett auf testing - denn da werden an Argumenten zwei Strings (ss) übergeben: https://github.com/yavdr/yavdr…0_softhddevice-03-end#L11

Bitte nicht stable-Pakete mit denen aus testing mischen und im Zweifelsfall lieber mittels apt-pinning die Pakete auf bestimmte PPAs festnageln:

#/etc/apt/preferences.d/testing.pref
Package: *
Pin: release o=LP-PPA-yavdr-testing-vdr
Pin-Priority: 1002


Package: *
Pin: release o=LP-PPA-yavdr-testing-yavdr
Pin-Priority: 1002


Package: *
Pin: release o=LP-PPA-yavdr-testing-xbmc
Pin-Priority: 1002

seahawk1986
Ich habe die yavdr.list komplett im testing, dann wird wohl nicht alles aktualisiert mit apt update, apt dist-upgrade.
Welches Paket ist hier nicht aus dem testing? Ich würde gerne mit apt-cache policy prüfen welche Version verwendet wird.

Quote from Frodo

Welches Paket ist hier nicht aus dem testing?

Ich würde mal auf yavdr-utils tippen (oder dass du noch ein altes Template rumliegen hast).

Stimmt:

apt-cache policy yavdr-utils
yavdr-utils:
  Installiert: 20130721191533stable-0yavdr0~precise
  Kandidat:    20130721191533stable-0yavdr0~precise
  Versionstabelle:
 *** 20130721191533stable-0yavdr0~precise 0
        100 /var/lib/dpkg/status
     20130708182408testing-0yavdr0~precise 0
        500 http://ppa.launchpad.net/yavdr/testing-yavdr/ubuntu/ precise/main amd64 Packages

Ohne Pinning oder händischem Eingriff dürfte das wohl schwierig werden beim update.

NACHTRAG:
Jetzt klappt es mit dem Ton, bei beiden VDRs.
Das vdr-frontend lässt sich nun stoppen und starten.

Somit dürfte die Lösung im Update des yavdr-utils liegen, zumindest bei mir hat das die Ton Probleme mit XBMC und VDR gelöst.

Dann führe mal folgenden Befehl aus oder mache das apt-pinning von seahawk1986:

apt-get install yavdr-utils=20130708182408testing-0yavdr0~precise

Wie man an der der Ausgabe von apt-cache policy sieht ist die Versionsnummer aus stable höher als im testing da testing früher erstellt wurde.
20130721191533stable > 20130708182408testing

Ausserdem solltest du die /etc/apt/source.list.d/yavdr.list anschauen dort sollte kein stable mehr Vorkommen.

Da Du folgende Befehle ausgeführt hast hast Du nun stable und testing Repositories in Deinen Quellen:
add-apt-repository ppa:yavdr/testing-yavdr
add-apt-repository ppa:yavdr/testing-vdr

Sicherheitshalber solltest Du das gerade ziehen. Die mit add-apt-repository hinzugefügten PPAs findest Du in /etc/apt/source.list.d.

Ist man schon immer komplett im testing hat man sehr wahrscheinlich die richtige Version von yavdr-utils erwischt, ich hatte aber Zeitweise stable-yavdr anstelle testing-yavdr in meinen PPA Listen, da das testing-yavdr bei mir nicht funktionierte.
Nach einem Hinweis, dass das nicht funktioniert bzw. zu Problemen führt habe ich das vor ein paar Tagen umgestellt und bekam dadurch yavdr-utils nicht mehr aktualisiert.

Es gibt im übrigen noch weitere Pakete welche in testing älter sind als in stable:

Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):
  vdr-tft-anthraize vdr-tft-pearlhd vdr-tft-standard yavdr-i18n yavdr-plymouth-theme yavdr-utils
  yavdr-webfrontend

Hi!

Super, danke euch. Hatte das gleiche Problem, Frodos Befehl hat geholfen. Die Stable PPAs habe ich jetzt mal auskommentiert.
Wie müsste ich denn bei einer Neuinstallation vorgehen, wenn ich Testing nutzen möchte? Zuerst die Stable PPA auskommentieren und dann erst Testing hinzufügen und update/upgrade?

Gruß

Bei einer Neuinstallation dürfte es reichen, wenn Du vor dem ersten "apt-get update && apt-get dist-upgrade" in der /etc/apt/source.list.d/yavdr.list alle "stable" Einträge durch "testing" ersetzt.

Wenn Du sicher gehen willst machst Du das apt-pinning was seahawk1986 weiter oben geschrieben hast.

Quote from BooStar

Als ich noch einen MischMasch aus sable und testing hatte, konnte ich in XBMC immer wieder so ein leichtes "pixel krisieln" feststellen.

Damit hattest du zwei VDPAU-Wiedergaben gleichzeitig aktiv - das führt zu den bekannten Effekten bei Pixeln mit der Overlay-Farbe.

Quote from seb_k

Wie müsste ich denn bei einer Neuinstallation vorgehen, wenn ich Testing nutzen möchte?

Die Regeln für apt-pinning anlegen (das ist der sicherste Weg zu bestimmen welche Pakete Priorität haben), neue PPAs hinzufügen, alte optional entfernen und dann wie gewohnt ein "apt-get update && apt-get dist-upgrade" laufen lassen.