Beiträge von stevie101

Ich nutze Grafdroid auf meinem Billigtab (WPDN). Ich glaube Android >= 2.3 ist notwendig für die bereitgestellte apk, das war eigentlich das Hauptproblem auf meinem ollen Tab. Ansonsten ist nix besonderes notwendig, ausser aktives WLAN und korrekte IP's. Mit Hilfe von adb auf dem vdr und einem upstart script startet GrafDroid, wenn der vdr aktiv ist, beim Runterfahren wird die App gekilled und somit die screen des Tabs aus. GraphTFT selbst ist bei mir 0.3.7.

asshep
Check doch mal den thread hier:

Remote VDR und Recordings vom anderen VDR werden nicht mehr aktualisiert während der Aufnahme

gemuesepudding

Vielen Dank dafür, klappt prima auf meinem ollen WPDN.

Schickt mir mal eure Mailadresse per PN. Ich lade gerade das image (ca.500MB) in mein Google sharedrive. Hab keine Ahnung wie ich es sonst machen soll.

Wenn das funktioniert und ihr das image runterladen könnt, dann solltet ihr:
a) vorher das reel beta image auf nen stick oder was auch immer installiert haben
b) die root partition des sticks auf nem anderen PC mounten (nehme an /dev/sdb1), den Inhalt löschen und das image darauf entpacken --> grub2 sollte dann alles finden
c) die resolv.conf anpassen, unter /etc/network/interfaces hab ich die S100 IP statisch eingegeben, auch die bitte nach Wunsch anpassen
d) die fstab anpassen (sind meine nfs Laufwerke drin und ne swap)
e) /etc/vdr --> eure channels.conf kopieren und die setup.conf anpassen (streamdev-client adressen, remotetimers, remoteosd, femonetc)
f) reelvdrd anpassen, ich hab dort die plugins hinzugefügt, zB. 2x streamdev-client wegen osdpip
g) gegebenenfalls die remote.conf, solltet ihr aber so auch klar kommen. zenegalircd wird einfach über reelvdrd gestartet

Wenn ich nichts vergessen hab, sollte das system booten. Telnet oder SSH entsprechend der vergebenen IP ist möglich.

Passt auf wenn ihr später was im Setup->Festplatte macht, das server video Verzeichnis muss "rw" gemountet werden, wenn ihr das was einstellt löscht der reelvdr erstmal den kompletten Inhalt.
Das image ist von meinem usb-stick. Hab ne 2.5 externe Platte mittlerweile dran, und dort auch timeshifting eingerichtet, das funktioniert. Es gibt Infos hierzu im Netz.
Ach ja, auf der Platte hab ich mittlerweile plymouth entfernt, auch hierzu gibt es Infos, wie man das am besten löst (ist einfach). Die boot-Zeit ist dann besser.
Ansonsten überprüft im /var/log was so alles Zicken macht.
Übrigens, skinreel3 ist ohne ImageMagick übersetzt, da gab es Probleme mit unresolved symbol, werd ich irgendwann nochmal schauen.
Als Tip, es lohnt sich nicht eine neuere Version des hdplayers oder linux.bin zu nutzen, hatte mit der Version aus testing Ruckler beim Abspielen von mkv's oder mp4's, mit dieser läuft es smooth.

Ich schau mal am WE, ob ich euch mein image irgendwo hochladen kann. Basis ist das Reel beta usbimage. Mittlerweile hab ich auch ne kleine Entwicklungsumgebung, da ich zwingend remotetimers brauchte und auch den neuen streamdev-client (sonst muss der Server < vdr-1.7.23 oder so sein). Graphtft läuft auch, das ganze auf svn testing, also vdr-1.7.21.4.
Funktioniert soweit prima, nach nen Jahr openelec, ist es mal wieder schön die Vorzüge des vdr's zu sehen.
Im Prinzip startet das Originalimage auch, ihr solltet nur mit "noplymouth" booten. Weiß nicht mehr genau, was dann die nächsten Schritte waren, aber prinzipiell kann man "reelvdrd" manuell ausführen und man sieht eigentlich wo es hängt.
Wie auch immer, das einzige was mich nervt, ist der bug mit statd, bzgl., nfs mount, da ich video, epg.dat und movie Verzeichnisse vom Server mounte, ist zwar nicht schön aber geht auch jetzt on startup.

Von uploads hab ich keine Ahnung, ich schau mal, allerdings hab ich nur ne kleine DSL Leitung

Zitat von SvenGWK

Ich hab das Beta auch mal probiert, läuft irgendwie auch nicht.
Ich bekomme von hdboot out of memory gemeldet, das dürfte das Programm sein was für das Linux image der eHD zuständig ist?

ja korrekt, dann initialisiert das Ding auch nicht. Wenn ich mich recht errinnere kannst Du hdboot (Angabe der Firmware und Adresse) manuell auf der shell ausführen, die LED auf der Karte sollte dann grün sein, am Ausgang liegt das reel Testbild.

Grundsätzlich ist die Kombo prima, man müsste allerdings das reelimage komplett entschlacken.
Ich muss mich mal ne Weile mit dem reelimage beschäftigen, mal gucken wann ich Zeit finde.
Leider hab ich keine i686 Entwicklungsumgebung mehr, daher kann ich mir Kernelmodul etc. nicht selbst bauen.

Gruss

hab mich auch mal an dem Reel usbstick image versucht.
- beim aufstarten kommt es zu jede Menge "out of memory"
- stop bei login --> maintenance
Hab daraufhin ein swapfile eingerichtet, allerdings wird es nicht verwendet - obwohl die fstab.conf angepasst ist.
Wie habt ihr das gelöst ?
Ansonsten mache ich alles manuell auf der shell läuft es soweit - reelvdrd angepasst. Konfiguration mit streamdev-client.
Dummerweise habe ich mein video Verzeichnis vom Server per nfs eingebunden - das sch**** Teil hat mir mein komplettes video Verzeichnis (600hrs) gelöscht, daher Vorsicht !
Mit der Fernbedienung hab ich auch Probleme, allerdings funktionieren die Farbtasten, dafür andere nicht - geht natürlich nicht wenn reelvdr per upstart gestartet ist.

Hallo zusammen,

nachdem mir eine Festplatte im Server an Heilig Abend abgeraucht ist, habe ich die Chance genutzt, und hab Debian auf dem Server aufgesetzt. Der Server bekam eine neue HD, eine SSD (OCZ Vertex2 Ext) und weitere 4GB RAM. Das ganze auf einem Gigabyte 870A mit AHCI. Da ich ngene brauchte, habe ich mir den Kernel 3.1.6 konfiguriert und installiert. Ich stellte dann fest, dass die performance der SSD bei rund 160Mb/sec liegt. Die gleiche SSD kommt in meinem Client auf 220Mb/sec. Debian läuft soweit rund, allerdings störte mich die SSD performance. Daher das Netz befragt und gelesen, das Trim am besten mit GPT funzt. Also System kopiert, SSD neu partitioniert [1 partition für BiosPart; 2 partition für system] (gdisk 0.51 ist grottig nach Formatierung mit Ext4 zeigte es immer "corrupted gpt" --> Lösung PartedMagic von USB Stick) und schliesslich neue Version von Grub2. System bootet, alles ok, allerdings SSD performance mit hdparm -t /dev/sda = 158 Mb/sec - keine Verbesserung. Trim gecheckt - alles ok. Scheduler ist noop.
Boote ich mein altes Ubuntu oder PartedMagic, liegt die performance, wie bei meinem Client, bei 220Mb/sec, nur wenn von der SSD gebooted wurde komme ich nicht über 160. Mit der Option "direct" zeigt mir hdparm ca. 230 Mb/sec.
Hatte die Vermutung das der custom Kernel dies verursacht (ich schmeisse alles raus was nicht benötigt wird), daher hab ich diesen mit der Debian "oldconfig" nochmals kompiliert, mit dem gleichen Resultat.
Hat jemand vielleicht eine Idee woran, dies liegt ?

Gruss
Stefan

mottobug
hab gerade gesehen, dass das feature bereits implementiert ist (aktuelles xbmc-pvr von pipelka).
Im context menu ("c") gibt es die Funktion "sort by date".

Gruss
Stefan

Pipelka's update läuft bei mir recht gut. Bildqualität (deinterlacing) in Bezug auf SD ist etwas besser geworden, allerdings auf "Servus TV" bekomm ich meist nur grünen Pixelmatsch. Aber prinzipiell sehr stabil und produktiv verwendbar.

Gute Frage - das stört mich auch gewaltig, der Überblick fehlt völlig. Vielleicht schreib ich mal einen feature request an pipelka.

Zitat von jrie

Hallo Stefan,
nimm mir bitte die Kritik nicht übel. Du hast Klötzchenbildung und glaubst dein Sat Signal sei das beste?
Jörg

Quatsch, ich veschlucke Wörter - sollte heissen "nicht das beste...".

Hallo zusammen,

vielen Dank für diesen Thread.

Hab nun endlich alte HW einem neuen Zweck zugeführt - ein streamdev server. Verbaut sind CineS2 (mit PCI-PCIe Adapter), TT-3200 und eine richtig alte WinTV Nova. Nach etlichen kleinen Problemen, stellte ich fest, dass die TT-3200 zur Klötzchenbildung neigt und lange für locks benötigt. Das SAT Signal in meinem Haus scheint das beste zu sein (6er LNB auf 80er Schüssel, möglicherweise muss die Ausrichtung korrigiert werden).

Mit der stb0899_algo.c von Lou wurde das Locking deutlich beschleunigt, allerdings nach wie vor Klötzchenbildung. Der stb6100_performance patch von Manu brachte hier eine wunderbare Verbesserung. Die patches wurden auf UFO's letzten ngene_test (v4l) Treiber angewendet. Zusätzlich der signal_strength und avoid-unnecessary-data-copying... Patch.

Bisher läuft alles bestens.

Gruss

Stefan

Zitat

mir geht der tv im schlafzimmer eigentlich nicht wirklich ab. auf der anderen seite: wir ham schon 3 kinder. ich BRAUCHE da einen

Der ist nicht schlecht

FireFly

kam gerade recht, nachdem mir aufgetragen wurde, den Nachbarn "die Säulen der Erde" zukommen zu lassen.
Die ersten beide Aufnahmen ließen sich einwandfrei brennen.

Danke.

Gruss

Stefan

Zitat

stevie: Hm, komisch, dass keine Ausgabe kommt. Muss ich mir noch mal angucken. Eigentlich müsste auch das mit dem DFBTerm dazu gehen, allerdings fürchte ich, dass beide (VDR-Plugin und Terminal) jeweils im "FULLSCREEN"-Modus laufen (DirectFB) und dann streiken wenn das jeweils andere läuft. Schau ich mir sonst auch noch mal an. Allerdings werde ich erst Sonntagabend, eher noch Anfang nächster Woche dazu kommen, glaube ich.

Na ja, muss auch nicht unbedingt parallel laufen, aber da ich die runvdr.sh nicht einfach killen kann, weil danach keine Ausgabe auf dem TV mehr erfolgt, funktioniert dieser workaround leider auch nicht. Im log ist nichts erkennbar, würde hier entweder auf directfb oder (sehe manchmal "IPC call failed") die Interaktion mit halserver etc. tippen. Im zweiten Fall sollte jedoch das OSD sichtbar werden, was jedoch nicht der Fall ist.

Gruss
Stefan

Mal ne Frage:
Grundsätzliches Problem ist, das sobald vdr/runvdr.sh gekilled werden, die runvdr.sh den vdr danach nie wieder starten kann (vdr läuft zwar aber keine Ausgabe). Danach muss die Kiste neu gebootet werden.
(halserver ? procman ? etc)
Da ich das Ding auch für Musik verwenden möchte, hab ich nach einer Möglichkeit gesucht, ncmpcpp (client für mpd) am TVout darzustellen. Das ganze läuft jetzt in dfbterm (danke Hawhill !) und lässt sich per irpty mit der remote steuern.
Ich möchte zwischen vdr und diesem dfbterm umschalten. Bekanntermassen kann man dafür das externalplayer plugin nutzen.
Wenn ich nun von vdr auf dfbterm umschalte, ist leider nichts sichtbar, obwohl dfbterm läuft. Das Problem ist ursächlich irgendwo in directfb (Speicher), möglicherweise innerhalb vom vip1710-plugin.
Wenn vdr / runvdr.sh manuell gekilled werden, funktioniert die Ausgabe von dfbterm. Danach komme ich aber leider auch nicht mehr zu vdr zurück.

Habt ihr eine Idee ?

Kurzes Feedback:

Streaming läuft rock-stable. Vielen Dank Hawhill !!!

Klasse, werd ich sofort testen.
Ja das mit der Zeitzone hab ich bereits probiert. Hab es in der plugrc gemacht (localtime gelöscht, neue mit Berlin verlinkt angelegt), war trotzdem immer auf UTC. Mache ich es händisch über telnet funktioniert es einwandfrei. Irgendwo hatte ich gesehen, dass die Zeitzone über settings.xml eingestellt wird ?

Hawhill
So konnte mittlerweile das neue Konzept ausprobieren.
Es funktioniert nun auch sehr gut mit vdr-1.7.15. Aussetzer kann ich keine feststellen, allerdings leider nach >20min bleibt das Bild stehen. Buffer usage geht plötzlich auf 100% und streamdev meldet lost connection, connection time out. Danach lässt sich nicht mehr umschalten, der vdr muss gekilled werden.
Lass ich auf einem Sender eine Aufnahme laufen, und schaue mir die Aufnahme parallel an, funktioniert es problemlos.
Zwischen der vip1710-Version 0.1.0 und 0.1.1 konnte ich keinen Unterschied feststellen.

Möglicherweise liegt es an streamdev, ich nutze die letzte CVS Version.

Mittlerweile nutze ich die Box :
a) Media server mit minidlna --> funktioniert selbst mit ca. 500 Gb relativ fix
b) MPD um Musik in meinem Hobbyraum zu hören. Da hatte mal jemand von hier mit einem schönen plugin begonnen, das als reiner Abspieler taugt. Sehr viel versprechend leider müsste da noch einiges gemacht werden. Muggle und Music hatte ich versucht, aber irgendwie funktioniert da die Ausgabe nicht (trotz OSS)
c) halt als streaming client für vdr

Ist nicht schlecht für 5,-€.