Beiträge von bärti

    Hi,


    mein Problem ist behoben, dummer Fehler meinerseits.

    Ich nutze live normalerweise hinter einem nginx als reverse proxy, wenn ich live direkt aufrufe, klappt alles wie es soll. Aus Gewohnheit hatte ich da nicht mehr dran gedacht. Ziemlich cool!


    Hier gibt es denke ich noch einen kleinen Bug, dann würde es auch hinter dem reverse proxy funktionieren

    Der HLS-Player versucht immer "/media/master_1.m3u8" zu laden, also mit "/" zu Beginn als absoluter Pfad.

    - direkt hinter live klappt das als http://home:8008/media/master_1.m3u8

    - der reverser proxy macht liefert live als http://home/live/ aus, da wird dann ein http://home/media/master_1.m3u8 - home/media gibt es aber nicht


    Eine Änderung von "/media/master_1.m3u8" nach "media/master_1.m3u8" sollte das beheben und auch hinter dem reverse proxy funktionieren.


    Ich habe mir das solange per nginx-config gefixt

    Code
    location /media/ {
            proxy_pass                            http://192.x.x.x:8008/media/;
            proxy_set_header Host                 $http_host;
            proxy_set_header X-Real-IP            $remote_addr;
            proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto    $scheme;



    ciao

    chris

    Hi,


    Idee finde ich super, jetzt bin ich auch endlich mal zum Testen gekommen. Allerdings bekomme ich weder in Chrome noch in Firefox ein Bild. Fehler Chrome:

    Cloud not play video - Error code: hls:4 - Firefox: FF: Error code: hls:networkError_manifestLoadError


    Als Inputs habe ich hier DVB-C über lokale DVB-Karte und sat-ip. Beides gibt selbes Fehlerbild - ich vermute es liegt irgendwie an der Erkennung des Video-Codecs (-analyzeduration 1.2M -probesize 5M)


    vdr log sieht eigentlich gut aus, ich denke es liegt irgendwie am Videostream (Consider increasing the value for the 'analyzeduration' and 'probesize' options)


    Wenn ich ffmpeg direkt starte, sieht es eigentlich auch gut aus, es werden diverse Files ffmpeg_5_data* erstellt, allerdings sind sie meistens (?) mit VLC nicht abspielbar

    Beispiel ARD HD per satip - Originalwerte -analyzeduration 1.2M -probesize 5M


    Alternativ ARD HD per satip - Werte für -analyzeduration 2.2M -probesize 10M

    eigentlich gleiche Fehlermeldungen, die Files ffmpeg_5_data* sind aber immer (?) mit VLC abspielbar


    Irgendwelche Ideen, woran das liegen kann? Bzw. welche Logfiles oder Tests helfen, den Fehler weiter einzugrenzen?


    Ausgangsbasis: vdr-2.4.0 auf Ubuntu 16.04 mit ffmpeg 4.0.3-1~16.04.york0 (von hier https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-4) oder auch ffmpeg N-47764-g16ec62bbf4-static (https://johnvansickle.com/ffmp…g-git-amd64-static.tar.xz)


    Danke

    bärti

    Hi,


    mit einem Skript kann ich nicht dienen. Aber für die Zukunft sollte helfen, dem vdr die Option "--vfat" beim Start mitzugeben.


    Zitat

    --vfat encode special characters in recording names to avoid problems with VFAT file systems


    wie man das bei yavdr macht, kann ich dir aber leider nicht sagen. Ist sicher irgendwo in /etc konfigurierbar.


    ciao
    chris

    Hi,


    I'm not sure about the exact release. I think it must have been an early 1.7.x release when the recording file size limit has been lifted to 1TB per recording. This should be enough for quite a while ;)

    Hi,


    ne, sollte eigentlich sauber alles in UTF-8 laufen. VDR meldet auch beim Start schön:

    Code
    codeset is 'UTF-8' - known


    Im Live-Plugin sind die Umlaute in der Kanalübersicht aber auch defekt, da steht dann "Sky Fu^ball Bundesliga". Aber es wird zumindest alles angezeigt. "WDR Köln" stimmt aber z.B. Scheint also wirklich mal wieder nur an Premiere/Sky zu liegen.


    ciao
    Chris

    Hi,


    so, habe noch ein bisschen weitergesucht und mein Gefühl war doch richtig ;)


    Lag nicht am EPG sonder das Problem sind kaputte Umlaute mit den Sky Optionskanälen. Der vdr selbst hat bei mir keine Probleme damit (zumindest mir Vearbeitung, Abo habe ich keins). Evtl. sind die EPG-Daten dieser KAnäle auch defekt, das habe ich noch nicht getestet.


    Auf der Projektseite habe ich jetzt mal einen Bugreport erstellt: http://projects.vdr-developer.org/issues/show/235


    ich hoffe das hilft erst mal weiter. Freue mich schon auf die nächste Version, die diesen Fehler behebt ;)


    danke und ciao
    Chris

    Hi,


    so, habe noch ein bisschen weitergetestet. Das komplette Log sind ~40k Zeilen, das wollte ich noch ein bisschen abspecken ;)


    Dabei konnte ich den Fehler zumindest einschränken. Ich hatte ja das Problem, dass kein LiveTV ging. Ich habe jetzt mal meine channels.conf zusammengestrichen, dass nur noch Das Erste, ZDF und Bayerisches FS Süd enthalten sind. Und, was soll ich sagen, damit funktionierts. Evtl. liegts also an irgendwelchen Sonderzeichen im Kanalbezeichner eines der anderen 475 Sender.


    Ich werde jetzt mal der Reihe nach das Log zurechtstutzen und dir die relevanten Teile auf der Projektseite einstellen. Dauert aber evtl. noch bis Mittwoch. Dafür die komplette channels.conf schon mal im Anhang.


    Ansonsten funktioniert Aufnahmenstreaming und LiveTV auch von XBMC (9.11-karmic1) aus. Dort sogar mit vor-/zurückspulen in Aufnahmen.


    danke und ciao
    chris

    So, jetzt habe ich das Plugin mal unter Ubuntu 9.10 mit gepatchter libupnp3 ein bisschen mit meinem B750 getestet:


    - Streamen von Aufnahmen funktioniert. Allerdings hatte ich das Problem, dass ich anfangs meine Aufnahmen mehrmals in der DB hatte, aber nur ein Eintrag abspielbar war. Evtl. lag das daran, dass bei den ersten Versuchen der vdr während der Erstellung der Aufnahmen-DB abgestürzt ist? Ich habe die metadata.db gelöscht, vdr neu gestartet --> alle Einträge sind abspielbar


    - Live-TV funktioniert leider noch nicht, muss ich aber noch genauer testen. mein TV sagt irgendwas von nicht unterstützt und dass er wieder ins Überverzeichnis wechselt.
    Ich weiß noch nicht genau, auf was ich im log achten muss. Auf die Schnelle ist mir Folgendes aufgefallen:
    Ich denke die Kanäle landen alle in der DB, log unten bekomme ich soweit ich sehe für jeden Kanal


    Allerdings kommen dann direkt danach (evtl. beim Zugriff per TV?) hunderte der folgenden Einträge:



    - Grundsätzlich hat der Samsung B750 Probleme mit Bildgröße und Seitenverhältnis. Es werden alle Aufnahmen in Verhältnis 4:3 angezeigt. 16:9 Aufnahmen dann eben verzerrt. Ist aber ein bekannter Fehler des TV und liegt nicht um Plugin.


    methodus: vielen Dank für die Arbeit an dem Plugin, macht soweit schon einen sehr guten Eindruck. Ich werde mit Live-TV noch ein bisschen rumtesten. Evtl. kannst du mir ja noch ein paar Tips geben, auf was ich dabei achten sollte?


    ciao
    Chris

    Hi methodus,


    super, vielen Dank für die schnelle Hilfe!


    sowohl unter Ubuntu 9.10 als auch 10.04 Alpha2 baut damit die gepatchte libupnp3. das upnp-Plugin läuft prinzipiell soweit auch, ich kann aber grad noch nicht testen. Nur der segfault beim Einlesen von Radioaufnahmen ist mir auch schon aufgefallen, ist aber ja schon bekannt.


    Zum Testen muss ich erst noch ein bisschen improvisieren, da mein vdr mit den DVB-Karten auf Ubuntu 8.10 läuft, das kann ich wegen anderer Serverdienste derzeit nicht updaten und das upnp-Plugin läuft da ja nicht mehr. Ich baue da aber grad eine lustige Konstellation mit einer zweiten vdr-Instanz in einer VM unter Ubuntu 9.10, angeschlossen an den anderen per streamdev-client... Warum einfach, wenns auch kompliziert geht ;)


    ciao
    Chris

    Hi,


    nachdem ich mit der Version 0.0.1 noch Probleme hatte, wollte ich micht jetzt mal über die aktuelle Version hermachen. Allerdings habe ich da noch ein Probleme:


    Da ich einen Samsung B750 habe, wollte ich die libupnp wie auf der Projektseite beschrieben, patchen. Allerdings bekomme ich immer



    getestet sowohl unter Ubuntu 9.10, 10.04 Alpha2 Was mache ich falsch?
    Unter 8.10 würde die libupnp bauen, allerdings sind da libavcodec und
    libavformat zu alt (svn20080206) und ich kann upnp nicht kompilieren.


    Im Wiki ist übrigens ein kleiner Fehler: patch -d1 sollte patch -p1 sein.


    irgendwelche Ideen?


    Danke und ciao
    chris

    Hi,


    zu Dual-Channel hatte wbreu glaube ich mal geschrieben, dass das Pflicht sei. Aber 1 GB reicht auf jeden Fall. Ich hatte hier noch 2x512MB aus dem Laptop rumliegen und wollte damit mein POV330 erst mal testen. Das läuft aber so problemlos, dass ich keinen Grund sehe, auf mehr RAM aufzurüsten. Wie herrlado hat hiervon die Grafikkarte auch 512MB, aber 512 fürs System reichen hier für xbmc und vdr-sxfe locker.


    ciao
    Chris

    Hi,


    naja, das ist das Problem, dass manche der sehr günstigen Receiver eben wirklich nur "HDMI Pass-Through" können. Du kannst sie zwar mit Bild+Ton per HDMI füttern, sie sind aber nicht in der Lage, den Ton zu extrahieren und nur das Bild an den TV weiterzureichen. Du musst dann per zweiter Verbindung, z.B. per optischem SPDIF, den Ton nochmal extra an den Receiver übertragen. Im Prinzip ist so ein Receiver nur ein recht teuerer HDMI-Umschalter ;)


    Beim Receiverkauf also immer aufpassen, dass der Receiver auch Ton aus den HDMI-Signal abgreifen kann.


    Als Bsp. kann das der Onkyo TX-SR 507, der günstigere Onkyo TX-SR 307 aber nicht. Beide haben aber HDMI-Anschlüsse, beim 307 aber mit IMHO sehr begrenztem Nutzen.


    ciao,
    chris

    Hi,


    als reiner Aufnahmeserver sollte ein Atom 230 absolut ausreichend sein. Ich habe einen P3 500MHz dafür, ist überhaupt kein Problem. Ich habe zwar kein DVB-S2 aber auch da sollten die Datenraten irgendwo zwischen 8-16MBit/s liegen und das stellt auch für diese Hardware kein wirkliches Problem dar. Wie gesagt, Aufnahme, nicht Dekodierung, aber das reicht in deinem Fall ja.


    Timeshifting mit Streamdev ist IMHO nur mit neuen Versionen (cvs?) möglich. Du nimmst die Sendung am Server auf und streamst die Aufnahme dann einfach zeitversetzt an den Client. Was hast du denn als Client vor? Evtl. wäre vdr-sxfe/xineliboutput oder xine besser (siehe vdr-wiki.de). Beide bieten dir auch das OSD des vdr, das kann Streamdev nicht.


    Allerdings scheint xbmc uns streamdev gerade rech fleißig weiterentwickelt zu werden. Wie ich das sehe sind damit mittlerweile LiveTV und streamen und programmieren von Aufnahmen möglich. Ansonsten könntest du z.B. auch einfach das Aufnahmeverzeichnis des vdr per nfs/samba vom XBMC-Client aus mounten und dort als normale Videos abspielen.


    Die Auslastung des Servers ist aber auch hier kein Problem, er packt ja einfach nur den Stream vom DVB Device ins Netzwerk (vereinfacht), also auch hier keine Dekodierung o.ä.


    ciao,
    chris

    Hi,


    danke für die Antwort, muss aber nochmal nachfragen ;-):
    Meine Befürchtung ist, dass ich im BIOS erst bei mehr als 1GB Gesamt-RAM der Grafikkarte 512MB zuweisen kann. Für VDPAU ist das ja nötig. Wäre halt nur doof, wenn bein 1GB RAM das BIOS mir nur 256MB oder so an die Grafikkarte zuweisen lässt. K.a. warum das so sein sollte, will eben nur sicher gehen. Aber wenn ich das in nem anderen Thread richtig gelesen habe, hast du eh 2GB RAM, oder?

    512MB RAM für das System reichen mir, das sollte kein Problem sein. Wichtig ist halt, dass ich 1GB RAM in 512MB fürs Grafik und 512MB für Rest aufteilen kann.


    ciao,
    Chris

    hi,


    entschuldigt bitte die Zwischenfrage. Aber hier scheinen sich ja einige mit einem POV/ION330 mit PCI-E rumzutreiben, an euch hätte ich eine Frage.


    Das Board würde ich mir auch gerne zulegen, v.a. da ich noch 2x512MB S0-Dimms aus dem Laptop rumliegen habe.
    Jetzt schreibt wbreu aber in Wie bekomme ich ein lauffähiges System für xineliboutput mit vdpau? dass man min. 2 Module a’1024 MB braucht, damit man der Grafikkarte 512MB zuweisen kann. Stimmt das auch für das POV?
    Bei mir soll voerst nur mms & vdr-sxfe laufen, da reichen 512MB RAM locker. Wenn ich allerdings im Bios der Grafikkarte erst bei > 1GB RAM 512MB Speicher zuweisen kann, bringen mir meine alten Module nichts mehr. Dann würde ich evtl. eher das POV/ION330-1 mit PCI nehmen.


    danke und ciao,
    chris

    Hi,


    ja, ich wäre evtl. auch noch dabei. Ich weiß aber erst Mitte nächster Woche definitiv, ob der Termin passt. Dann muss ich mir noch überlegen, wie ich am besten zu dir komme. Aber wie ich das sehe, sucht gnapheus eh Mitfahrer und kommt aus der gleichen Ecke ;-). Muss ihn gleich mal fragen...


    Ich sag dir spätestens Mittwoch definitiv Bescheid, Chancen stehen aber gut.


    ciao,
    chris

    Hallo,


    ich nutze zwar kein vdpau, wegen


    Zitat

    Weiterhin funktioniert jetzt auch die "grab"-Funktion zusammen mit vdpau so das man auch wieder ein Bild im vdradmin hat. Funktioniert aber nur optimal mit gepatchter xine-lib.


    wollte ich jetzt aber doch mal xineliboutput-1.0.4-vdpau-support-v6.diff.gz testen. Damit sollte ja die Vorschau im live-Plugin auch funktionieren.
    Ich habe also _nur_ diesen Patch gegen xineliboutput-1.0.4 angewendet, keine weiteren Patches der xine-lib. Das Ergebnis ist

    Code
    In file included from xine_sxfe_frontend.c:204: 
    xine_frontend.c: In function ‘fe_grab’: 
    xine_frontend.c:1709: error: ‘vo_frame_t’ has no member named ‘proc_provide_standard_frame_data’ 
    xine_frontend.c:1712: error: ‘vo_frame_t’ has no member named ‘proc_provide_standard_frame_data’ 
    xine_frontend.c:1724: error: ‘vo_frame_t’ has no member named ‘proc_provide_standard_frame_data’ 
    xine_frontend.c:1668: warning: unused variable ‘img’ make: *** [xine_sxfe_frontend.o] Error 1


    Muss ich also die xine-lib auch patchen oder woran scheitert das noch? Gebaut wird das ganze unter Ubunut 8.10 mit libxine1 und libxine-dev beides in aktueller Version 1.1.15-0ubuntu3.3.


    danke und ciao,
    chris

    Hi,


    ich kann meinen Vorpostern nur zustimmen. Am einfachsten ist es, du nimmst was fertiges.
    Ich habe schon > 1 Woche erfolglos versucht den Inteltreiber der für Scart notwendig ist unter Ubunut 8.04 zum Laufen zu bringen. IIRC war das Problem, dass der X-Server von Ubuntu zu neu ist aber einige Teile davon nur als fertiges Binary vorliegen. Jetzt läuft auch ein selbstgebautes System, aber eben ein Debian Etch, auf dem auch die meisten fertigen Images basieren. Damit funktioniert der Intel-Grafiktreiber problemlos. Wenn du also unbedingt selber basteln willst, fang mal mit Debian Etch an.


    ciao,
    chris