Beiträge von schlingel

Hallo , ich verwende eine "revolt Automatische USB-gesteuerte Steckdosenleiste" welche an dem Fernseher angeschlossen ist . Wenn der Fernseher ausgeschaltet wird per Fernbedienung oder durch durch Inaktivitätstimer schaltet er auch gleich den raspberry pi , Verstärker , DA-Wandler und Switch mit ab .

Hallo ,
ich hatte neulich beim Update auf xbmc13 ein ähnliches Problem,
HD Filme ruckelten wie die Pest .
Der Fehler lag bei mir komischerweise beim der Audio-Ausgabe .
Schau mal nach , ob der bei dir auf Anzahl der Kanäle auf 2.1 steht , und wenn ja stell ihn auf 2.0 um .
Mein Client ist ein Acer Revo R3600 ( singel core Atom ) und bewältigt sogar 2D Ausgabe von 3D HD Filmen Problemlos .

Ich bin zwar mit meinem SMB/Wlan-Problem zur Lösung gekommen , aber mit der Umstellung auf NFS scheint jetzt alles unter XBMC zu laufen .
Das kreisenden „Arbeitet...“ ist verschwunden . Selbst 33GB Files laufen ohne nennenswerte Meldungen im debug und syslog log komplett durch .
Nur bei BigStepForward verhaspelt er sich für ca 1 sec .

Danke nochmal für deine Updates seahawk1986 , da bei früheren XBMC Versionen NFS per sources.xml bei mir noch nicht Funktionierte .

zu dem Zweck habe ich ja auch eine Asus RT-AC68 in Kombination mit einem Edimax AC1200 angeschafft .
Keine anderen 5GHz Netzwerke ausser diesem sind sonst vorhanden . Eine 1k iperf Schleife zeigte auch keine nennenswerten Schwankungen . Der nebenbei laufende Ping hatte auch keinen einzigen Packet lost .

Hallo ,
danke für das weitere Update .

Wo liegen eigentlich die Unterschiede zwischen smb unter XBMC und dem normalen mount der shares ?
alle meine Clients laufen mehr oder weniger Problemlos , bis auf einem per Wlan angeschlossenen Revo .
Dieser macht nur Schwierigkeiten . unter Streamdev bleibt er nach ca 30 Minuten das Bild stehen und kann nur durch hin und her schalten zur weiterarbeit bewegt werden .
Aber noch schleierhafter ist mir das Verhalten des XBMC .
Ein mount //DS1512/video /X ist Problemlos , aber unter xbmc ist das Glückssache .
Ein Zugriff auf smb:// verursacht ein 3 minütiges arbeiten ohne ergebniss .. nochmaliger zugriff zeigt dann komischerweise die Arbeitsgruppen . Beim Zugriff kommt dann aber "Operation not Permited"
Im xbmc.log steht dann manchmal : unix_err:'1' error : 'Operation not permitted' oft friert dann xbmc einfach ein .
bei Linux shares kommt manchmal : ERROR: GetDirectory - Failed to stat file smb://.......................
Was läuft bei Wlan anders ? Ein fast identischer Revo über Lan angeschlossen hat diese Probleme nicht .
Irgendwelche Tips , wie ich diese unberechenbare Verhalten von SMB unter XBMC fixen kann ?

Danke im voraus

Danke ,
endlich eine Lösung für das Menüchaos bei 3D und keine extra 2D Versionen für Clients ohne 3D Fernseher .
Jetzt fehlt eigentlich nur noch dass XBMC beim Fernseher den 3D Modus steuern kann .

Ich installiere gerade nebenbei einen Server mit testing vdr .
Doch dein Tip mit den verschieden Verzeichnissen und Meta Daten auf einer SSD war zu verlockend .
Die Aussicht auf eine (fast ) Instant Anzeige der Aufnahmen wollte ich nicht ungenutzt lassen .
Das Verhalten von video.00 / video.01 werde ich dann am lebenden testing-Objekt sehen .
Ich hoffe nur die .ts Files verteilen sich nicht so , wie damals mein .vdr files auf meinem linvdr Kreuz und Quer zwischen den Video Verzeichnisen mit symlinks .

Danke nochmal

Schlingel
p.s. Für ein Script mit dem man die bestehender Aufnahmen in ein video.00 (ssd mit meta daten ) und ein video.01 ( .ts Files ) splitten ( mit anlegen der Symbolischen links ) und ein 2tes script für das zurückführen in ein Verzeichnis wäre ich überaus dankbar .

aus meiner Sicht gehe ich von folgenden Daten aus :

Yavdr-Server :
video.00
: ( verzeichnisnamen ; index ; info ; marks und sym links auf .ts
dateien in video.01 ) auf localer nicht freigegebener SSD
video.01 : ( verzeichnisnamen und .ts dateien ) mount vom NAS ohne index info und marks

Clients :
video.00
: locale SSD für mich bisher unklar woher die index info und marks
kommen sollen da kein mount vom Yavdr-Server ( soll ja auch bei nicht
laufendem server funktionieren )
video.01 ( verzeichnisnamen und .ts dateien ) mount vom NAS ohne index info und marks

gda wenn video.00 mit index etc auf dem yavdr-server liegt und die .ts auf dem video.01 auf dem nas , haben die clients doch keinen zugriff auf die index dateien oder ?

gda sowas wäre klasse . aber sind die meta daten nicht die index ; info und marks ? falls ja , muss dann jeder client für jede aufnahme die index datei neu erstellen und muss man für dieses erstellen nicht alle .ts files komplett lesen ?
Bei 7TB und etlichen Clienten , wobei einige über wlan angebunden sind wird das wohl mehr als eine Woche dauern .

btw : habe gerade einen Rechner mit 2.02 testing-vdr gebootet und kann Mreimer recht geben ... dort reagiert das osd unabhängig vom Videoverzeichniss und man sieht , wie sich das Aufnahmeverzeichnis langsam nach und nach aufbaut .

Danke für die schnellen Reaktionen
gda : ich mounte bei allen meine Clients das /srv/vdr/ Verzeichniss direkt vom NAS , damit ich auch bei nicht laufendem Server die Aufnahmen im Zugriff habe .

Funktioniert die video.00 / video.01 Sache dann auch noch ? oder muss ich dann eine SSD für das video.00 ins NAS einbauen ?
Ist diese Aufteilung von .ts und metadaten abhängig von den Verzeichnissnamen oder von deren Größe ? ( ich schieße oft mit Kanonen auf Spatzen und würde wahrscheinlich eine 128GB SSD für das video.00 verwenden )

Da man auf das OSD anscheinend immer
solange warten muss , bis der Rechner das komplette Videoverzeichniss
eingelesen hat ( ein ls -R des auf dem NAS liegenden Verzeichnisses
dauert bei mir bis zu 14 Sekunden ) , habe ich über SSD-Caching auf
dem NAS nachgedacht .

Besser würde mir natürlich gefallen ,
wenn es eine Lösung geben würde , die die Directorystruktur im
Speicher halten würde , oder eine Option die das OSD von dem
einlesen das Verzeichnisses entkoppeln würde .

Ich weiß auch nicht , ob die von
Synology eingesetzte flashcache
Variante die Lösung meines Problems wäre .

Bevor ich jetzt nochmal ca 600€ für upgarde auf eine ds1813 oder eine
dx513 mit 2 SSDs + Speichererweiterung ausgebe wäre ich für
Ratschläge dankbar .

Gruß

der Schlingel

Wie wechselt man vom normalen 0.5er auf das testing vdr 2.0.2 ?

Hi ,
schau doch mal mit : nfsstat -m
nach , mit welchen Optionen dein manueller mount läuft .
wie in Aufnahme-Ordner per NFS mounten ausgeführt kann die Nfs-Version des Nas extreme Auswirkungen haben .

Gruß
Schlingel

Hallo ,
ich würde gerne einen Dummy Eintrag als Startchannel für meine Streamdev-clients haben , damit bei nicht laufendem Server das OSD des Clients nicht so harkelt und die Fehlermeldungen verschwinden .
Ein Workaound mit einem localen iptv ,welcher nur ein schwarzes i-frame sendet, ist mir dazu bisher eingefallen .
Allerdings fehlen mir bisher leider die Kenntnisse dieses selber zu realisieren .

Gruß
Schlingel

Das System ist , bis auf s* vom guten freund ohne cs und xbmc+vnsi von seahawk1986 , vanilla ( erst vor 3 tagen von beta auf final 0.5 umgestiegen )
Hardware ist eine Stromspar Dualcore Sandy mit 4 tuner cine v6 mit ssd und einer Synology 1512+

nfs optionen in der fstab sind : auto,user,async,rsize=32768,wsize=32768,intr,noatime,vers=3,tcp

im syslog nur folgende Meldungen :

Feb 25 17:30:50 Yavdr-Server vdr: [16368] Text2Skin: menu display update thread ended (pid=1337, tid=16368)
Feb 25 17:31:01 Yavdr-Server markad: [15988] resuming after 15s of interrupted recording, marks can be wrong now!
Feb 25 17:31:02 Yavdr-Server markad: [15988] recording interrupted, waiting for continuation...

wobei markad sich kontinuierlich wiederholt .

falls jemand eine Idee haben sollte , wie man das Eindösen des OSD vermeiden kann , währe ich für Tips dankbar .

Gruß
Schlingel

Hi , seit ich mein Videoverzeichniss auf meiner Synology habe , wurden mir die damit zusammenhängenden Probleme bewust .

1. Vdr startet bevor das Aufnahmeverzeichniss da ist .
-> Lösung ist in yavdr 0.4 als client-vdr. nfs mount auf /srv/vdr/video.00 klappt nicht beschrieben : siehe nfs_warte.conf .

2. OSD braucht teilweise 17 sec um zu reagieren , ohne das ein Hinweiss im syslog dazu auftaucht .
-> Sehr gross Verbesserung brachte [gelöst][yaVDR 0.5 alpha/beta] OSD träge : der Eintrag vers=3 in den nfs options der fstab hatte extreme Verbesserungen zur Folge ,

Das OSD hat zwar noch immer ein wenig das Verhalten , als ob nach ein paar Minuten die Platte herrunter fährt und bei Aufruf neu gestartet werden müste , was dank SSD ausgeschlossen werden kann .

Warum ein nfs mount des Videoverzeichnisses Einfluss auf die Reaktionszeiten des EPG und Timer Menüs ( teilweise bis zu 7 sec ) haben ist mir nicht ersichtlich .

Gruß
Schlingel