Beiträge von SvenS

    So hab jetzt mal auf den zuletzt aufgesetzten Raspi geguckt. Der läuft unter Raspbian Jessie auf einem Raspi 3 mit vdr 2.2 und skinflatplus 0.6.0 seit knapp zwei Jahren stabil. Das Skin ist also im git das hier. Das reduziert die zu überprüfenden commits schon mal drastisch.


    Soweit ich mich an meine letzten Tests erinnere war das Problem aber evtl. auch im Zusammenhang mit Raspbian Stretch zu sehen. Damit hatte ich wenn ich mich Recht erinnere das Problem aber auch das müsste ich dann nochmal überprüfen.


    GTRDRIVER welche Raspbian Version setzt Du ein?

    Hab noch keine Lösung dafür gefunden und die letzten Tage leider keine Zeit gehabt das zu vertiefen. Der einzige Raspi auf den ich gerade draufkomme hat diese Version (irgendwas zwischen 5.1 und 5.2) Also gut abgehangen aus 2015. Läuft aber stabil seit langer Zeit. Wir müssen dann wohl mal den Commit identifizieren ab dem es nicht mehr geht.


    Wenn ich ins Git gucke dann könnte diese Version hier ein guter Kandidat sein bei der Kompatibilität für 2.3.1 eingefügt wurde.


    Welche Version benutzt Du, die aktuellste?


    bye

    Sven

    Den Effekt kann ich bestätigen. Interessant war bei vergangenen Versuchen, dass das von der Betreibssystemversion abhängig schien. Eine identische vdr Umgebung von einem anderen raspi mit älterem raspbian kopiert und neu gebaut zeigte den Effekt, auf dem Spender raspi läuft alles normal. Ich hatte es meiner steinalten epgd version (noch ohne httpd) zugeschrieben und nicht weiter verfolgt.


    bye

    Sven

    Hi,


    unter einem aktuellen Raspian hat skinflatplus Probleme gemacht, die EPG Texte waren nicht mehr sichtbar. Unter Raspian jessie kein Problem, da habe ich das auf 4 Raspies laufen und ich habe die Sourcen damals 1:1 auf das aktuelle Raspbian rüberkopiert und neu gebaut, d.h. es war eindeutig das Betriebssystem. Hänger vom OSD gab es auch immer wieder.


    Welchen skin verwendest Du? Default?


    bye

    Sven

    Beim Lesen eurer Beiträge ist mir gerade eingefallen das ja ab 2.3 diese Problematik losging und sich eigentlich bis zur 2.4 hingezogen haben. Also würde ich zur Analyse ein neues System aufsetzen und die 2.2er testen und wenn die läuft auf die 2.4er wechseln.


    Wie gesagt, ich hab hier 4 Raspis (2er und 3er) unter VDR 2.2 die laufen alle stabil. Allerdings ist das Thema mindestens zweigeteilt. Einmal die Probleme mit vdr 2.4 und einmal Debian (Raspian) Stretch. Bei Versuchen vor einiger Zeit hatte ich zahllose Kleinigkeiten auch bei einer vdr 2.2 Installation. EPG texte nicht mehr sichtbar. OSD Hänger usw. Ich hab dann einfach einen funkionierenden (Jessie) Klon eines der anderen RPIs genommen und gut war.


    D.h. für mich im Moment das wir erst mal einen 2.2er auf Raspian Stretch stabil bekommen müssten bevor wir über 2.4 reden. Das werde ich am Wochenende mal probieren. Hier sind es soweit ich bisher getestet hatte definitiv Probleme mit diversen libs die ich aber wie oben geschrieben aus Zeitgründen damals nicht weiter verfolgt habe.


    bye

    Sven

    Hi,


    sagen wir so, ich habe hier im Haus insgesamt 4 VDR Clients am laufen. Alle unter 2.2 und die laufen stabil, Hänger treten da wenn überhaupt vielleicht einmal im Monat, eher seltener auf. Das ganze unter Raspbian Wheezy oder Jessie. Unter Debian 9 Stretch gibt es einige interessante Effekte mit rpihddevice wegen lib Problemen, egal ob vdr 2.2 oder 2.4. Interessante Effekte gibt es dann auch mit z.B. dem skinflatplus das auf einmal keine EPG details mehr anzeigen will, classic oder lcars skin geht.


    Was ich damit sagen will es gibt offenbar einige Abhängigkeiten die zu den o.g. Effekten führen. Was ich am Wochenende ausprobieren möchte ist ein sauberes Raspbian Image als Basis aufzusetzen. Dort dann zunächst einen plain vanilla vdr 2.4 nur mit rpihddevice und streamdev. Bisher habe ich dafür nie irgendwelche patches benötigt, weder für den vdr noch streamdev.


    Offenbar gibt es aber, was ich in der letzten Zeit nicht wirklich verfolgt habe, durch diverse 2.4er Änderungen an den lock Machanismen hier Bedarf an Patches. Das muss ich mir auch erst mal noch anschauen.


    Irgendwelche 2.3.x Versionen zu verwenden halte ich im ersten Schritt nicht für zielführend, denn wenn das läuft holt man sich wieder unbestimmte Probleme mit hinein durch Plugins die 2.4 voraussetzen (evtl. auch nur unabsichtlich) . Wenn 2.4 gar nicht stabil zu bekommen ist würde ich persönlich den Schritt zurück zu 2.3er Versionen lediglich zur Analyse machen wollen.


    bye

    Sven

    Ja wäre auch eine Möglichkeit. Ich habe seit 2002 im Prinzip die gleiche Struktur wie ich einen VDR aufsetze. Die ist was die Dateistruktur betrifft recht unterschiedlich zum aktuellen Stnadard, deshalb habe ich immer direkt aus den Sourcen gebaut. Hat auch bisher geklappt bis zu raspbian Sarge mit den oben beschriebenen Problemen. Wie gesagt, ich vermute das das an irgendwelchen libs liegt und evtl. die Patches das lösen.


    Muss mir das die Tage mal wieder genauer ansehen. Ein momentan ungenutzter Raspi 3 liegt hier noch rum werde den dann mal zum testen nutzen und von Grund auf ein neues Image bauen.


    bye

    Sven

    Oh ja da bin ich dabei. Und geht mir genau so mit den fertigen Distris bin ich nie warm geworden und meine momentane Umgebung unter 2.2 läuft seit Jahren stabil und im Prinzip wartungsfrei.


    Würde aber mittelfristig auch gerne 2.4 einsetzen um die Plugins für remote timer z.B. in Rente schicken zu können. Das läuft hier dann aber im Prinzip auf einen Neubau der Softwareumgebung hinaus, das hat mich bisher davon abgehalten.


    Davon abgesehen hab ich als ich letztlich einen alten wenig genutzten RPI 1 Client auf einen aktuellen Rpi 3 upgraden wollen. Einer meiner Clients ist bereits ein Rpi3 die anderen sind Rpi2. Der neue 3er war nur mit dem nie upgedateten Image des existierenden 3ers zum laufen zu bekommen. Ein neu aufgesetztes Raspbian Stretch hatte immer Hänger beim Menü bedienen. Ich hatte das irgendwann dann mal auf irgendeine Lib heruntergetrackt dann aber einfach das laufende Image gecloned und war zufrieden damit und hatte keine Lust mehr weiter zu suchen.


    Würde bei einer Neuauflage wieder da ansetzen und erst mal einen nackten VDR 2.4 als Raspi Streaming Client mit streamdev aufsetzen wollen und sehen wie das ohne weitere Plugins läuft. Dann die (für mich zumindest wegen WAF) wesentlichen Plugins (Fritzbox, SkinFlatPlus).


    bye

    Sven

    Nur falls jemand beim Suchen der Fehlermeldung hier vorbei kommt. Das Problem mit Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]* hatte ich am Wochenende bei einem Raspi 3 unter aktuellem Raspbian Stretch gehabt. Lösung dafür war in /etc/lirc/lirc_options.conf


    Code
    1. driver = default
    2. device = /dev/lirc0

    einzutragen. Wenn ich mich richtig erinnere war vorher als default


    Code
    1. driver = devinput
    2. device = auto


    Danach war Ruhe im Logfile und die Fernbedienung hat wieder funktioniert. Keine Ahnung ob das unter Jessie auch so beim installieren gesetzt wird, da alle meine Jessie Instanzen in Place upgrades waren. Der TE hat sein Problem ja durch eliminieren von lirc gelöst bekommen, das geht ja aber nur wenn man eine FF Karte mit IR Anschluss im system hat.


    bye

    Sven

    Hab noch epgd vor httpd am laufen und das gleiche Problem. Hab gerade epgdata zum Hauptprovider gemacht und es sind wieder Daten wie gewohnt da. Scheint also eindeutig ein tvm Problem zu sein.


    bye

    Sven

    so, jetzt mache ich ein langes Gesicht und bin froh, mit niemandem gewettet zu haben.
    Das Leihgerät (eine W724V Typ B) zeigt im sppedtest einen Download von 48,3 Mbit/s, einen Upload von 10,64 Mbit/s und einen Ping von 14ms.
    Vorher waren es 10-18 Mbit/s, 1,8 Mbit/s und 39ms.


    Also liegt es doch an der Umstellung des Anschlusses auf BNG und damit verbundener Inkompatibilität meiner Fritzbox. Nun habe ich ja schon öfters den Rat bekommen, mir mal eine neue zu kaufen und werde dies zähneknirschend in Gestalt einer 7490 jetzt wohl auch tun. Trotzdem ärgert es mich, und ich werde bei der Telekom versuchen, eine Gutschrift rauszuschlagen. Die 7570 habe ich vor 4 Jahren als Restposten erworben, da war sie schon 2-3 Jahre auf dem Markt. Schon kurz nach dem kauf hat AVM den Support eingestellt, weil sie zu alt sei (damals noch nichtmal 3 Jahre).

    Es widerstrebt mir, ein an und für sich funktionsfähiges Gerät wegzuwerfen, nur weil der Vertragspartner eine einseitige technishce Änderung durchführt, von der im Prinzip nur er profitiert.


    Die 7490 ist ja auch schon eine Weile auf dem markt. wahrscheinlich stellt AVM dafür dann den Support auch 2018 oder 2019 ein. Das kann m.E. alles nicht richtig sein.

    Hi,


    na ja die 7570 wurde 6/2009 eingeführt, d.h. mittlerweile vor über sieben Jahren. Support wurde 2012 eingestellt und obendrauf wurde die wohl nur als OEM verkauft, d.h. nicht direkt an Endkunden. Die 7390 wurde 2010 auch für Endkunden eingeführt und erhält immer noch updates es ist also zu Erwarten das die 7490 die bis Anfang des Jahres noch das Topmodel war noch einige Jahre Updates erhält. Waqs die updatepolitik betrifft ist AVM sichere als einer der Besseren Hersteller zu betrachten.


    Aber davon abgesehen, die Einschätzung das ein Gerät noch einwandfrei funktioniert ist bei Netzwerkkomponenten eben auch von der Umgebung abhängig. Sollte die Telekom bei jedem Anschluss erst prüfen welche Endgeräte dranhängen und ob eine Änderung auf deren Seite evtl. alte Schätzchen überfordert? Da wäre das Wehklagen ob des mangelnden Fortschritts und den erhöhten Kosten für so ein Vorgehen sicher groß.


    Wir müssen auch auf Consumerseite einfach zur Kenntnis nehmen, das Geräte ab einem gewissen Alter zwar elektrisch noch funktionsfähig, aber wegen Inkompatibilitäten im Prinzip als defekt zu betrachten sind. Von Sicherheitsupdates und der wirtschaftlichen Unmöglichkeit Geräte beliebig lange damit zu versorgen will ich da noch gar nicht anfangen.


    Wir wollen alle schnellere Zugänge und solange nicht Glas im Haus liegt aus dem natives Ethernet fällt werden wir wohl mit dem Wechsel unserer Router Hardware alle paar Jahre leben müssen.


    bye
    Sven

    Hi,


    hier auch nur gute Erfahrungen. Habe zwei RPI2 und einen RPI1 als streamdev client. Zwei per Kabel versorgt einer per Powerline und laufen alle stabil. Powerline Adapter sind alle von AVM und unauffällig, das Haus und die Installation sind aber auch erst 15 Jahre alt.


    Hab gerade die Tage einen RPI3 und ein USB DVB device bestellt um den Client VDR im Wohnzimmer damit zu ersetzen. Mal sehen über den Winter will ich mal etwas mit Netboot rumspielen. Wäre schick wenn die Kisten nur noch den bootloader auf der SD karte hätten und alles andere auf dem Server liegt. Bin mir nur nicht sicher wie sich das mit epgd verträgt. Aber ist ja so schön einfach mit verschiedenen SD Cards das auszuprobieren ;-)


    bye
    Sven

    Hi,


    ich baue seit nun 14 Jahren meine VDR Versionen immer selbst (scheiße ist das lang her...). Und dabei nutze ich die althergebrachte Methode unter /usr/local/src ein Verzeichnis mit der jeweiligen Version anzulegen und dort auch zu bauen. Die VDR binaries bleiben ebenfalls dort und werden nicht per make install über das system verteilt. Ein symlink VDR zeigt dann auf die jeweils aktive Version. Will ich dann eine neue Version testen dann ändere ich nur den symlink.


    Dieses Vorgehen setzt aber wie auch die Paketmethode ausreichende Kenntnis in Linux Administration und zumindest grundlegende Kenntnisse wie man binaries baut bzw das make file anpasst voraus. Eine gute Anleitung gibt es hier von Hubertus.


    Dieses Vorgehen hat sich bei mir bewährt, da eine Liste der installierten Debian Pakete des laufenden Systems, eine Kopie des /etc und /usr/local/src ausreichen um mit minimalem Aufwand die Installation umzuziehen (hab ich in den Jahren bestimmt drei oder vier mal so gemacht wenn ein neuer Server her musste). So sind auch meine Raspi Clients alle aus der gleichen Installation gecloned die auf dem VDR Server läuft. Überall sind alle Sourcen vorhanden, das war vor allem wichtig als noch reichlich patches notwendig waren.


    Gerade wenn 2.3 testen gewollt ist würde ich für die produktive Nutzung noch eine 2.2 er Version parallel halten, wie oben schon gesagt sind noch nicht alle Plugins bereit für 2.3. Wenn dann im Herbst evtl. Klaus wieder mehr Zeit hat und neue Versionen kommen ist die parallel Installation auch hilfreich um zwischen verschiedenen Varianten hin und her zu switchen und nachher, dem häuslichen Frieden willen immer ein lauffähiges System zu behalten, wenn man kein dediziertes Testsystem hat.


    bye
    Sven

    Hi,


    kenne das Problem. Hab viele Mäuse ausprobiert und die einzige die rundum glücklich macht ist die von https://evoluent.com/. Nicht ganz billig aber wenn man den ganzen Tag am Rechner arbeitet lohnt sich das. Gibt es hier als Version 4 oder hier als Version C (die neuere).


    Wenn es günstiger sein soll dann geht die von Anker (gibt es auch von anderen Anbietern) hier.


    Ich bevorzuge die Evoluent seit ein paar Jahren da alle Hand/Armprobleme bei mir innerhalb kürzester Zeit weg waren und die Handhabung sehr bequem ist nach kurzer Eingewöhnung. Die Anker Maus ist o.k. und besser als eine normale aber für meine Hand ein bischen zu klein.


    Ach ja und Gummi haben alle o.g. nicht.


    bye
    Sven