Beiträge von MikeDK

    das gleiche problem hab ich auch ... liegt anscheinend am verstärker ... bzw. nicht nur: ich denke, dass alsa nach dem spielen eines sounds den audioausgang wieder freigibt ... und dadurch weiss der verstärker nicht mehr, welches audioformat er bekommt, und schaltet in nen auto-erkennungs-modus ... sobald dann wieder sound von alsa ausgegeben wird, erkennt der verstärker das format, und es funzt ... allerdings fehlt durchs erkennen ein bisserl zeit ...


    bei manchen verstärkern kann man diese auto-erkennung abschalten, und z.B. fix auf PCM stellen ... dann sollte dieses problem behoben sein ... (allerdings könnte es dann probleme geben, wenn man plötzlich mit nem andren format rausfährt ... ac3 z.B.)


    oder aber, man sagt alsa irgendwie, dass es nach dem spielen eines sounds den ausgang nicht komplett freigeben soll ... nur keine ahnung wie man das macht ...


    ist aber eines der 168 dinge auf meiner vdr todo list, hehe

    newsy: bei ard-hd und zdf-hd hab ich genau dasselbe ... ich glaube das liegt daran, dass die deutschen öffentlich rechtlichen sender das einfach nicht implementiert haben
    auf anixeHD krieg ich z.B. nichtmal den balken, da sagt er gleich, dass kein teletext verfügbar ist
    aber probier doch bitte mal den teletext auf servustvHD ... dort sollte einer sein (hab ich erst gestern kontrolliert)
    naja ... und mit dem patch sollte es dann auch auf orfHD gehn ;)


    löwe: aha ...? ich dachte beim yaVDR ist der extension patch mit drin ... weil ja der wwoody gemeint hatte, dass bei ihm teletext auf orfHD reibungslos funzt ...
    im zweifelsfall würd ich den vdr einfach selbst kompilieren ... aber ich weiss leider nicht, mit welchen problemen das in yaVDR verbunden ist ...

    schon wieder so ein teil, das irgendwo versteckt in einem thread steht, dessen topic rein gar nix mit der funktion zu tun hat ... wie soll man sowas denn finden/kennen?


    abgesehen davon soll mein tool die Lircmap.xml UND remote.xml erstellen, und dann idealerweise gleich ins richtige verzeichnis kopieren ...


    aber eigentlich wärs noch viel netter, wenn ich das gleich direkt ins xbmc einbaun könnte ... so ala system/eingabegeräte/lirc fernbedienung anlernen ...


    nur: wenn sowas von den xbmc entwicklern eh schon geplant sein sollte, mach ich mir nur wieder arbeit umsonst ... :/


    und nachdem ich in keinem dieser elitären kreise verkehre, wo man alles weiss ... lass ichs lieber *hmpf*

    ok ... testen könnt ihr euch ersparen ... derselbe patch ist schon im vdr ExtP-NG drin, wie ich grad durch zufall rausgefunden hab ... also dürfte das schon länger ohne probleme laufen ;)

    naja, der patch ist ja trotzdem vielleicht interessant fuer alle ösis, die nicht den extension patch installieren wollen ...


    und zumindest kann man sich das testen jetzt ersparen ... anscheinend lauft das schon ne recht lange zeit ohne probleme bei den extension patch usern


    trotzdem ärgerlich ... hab soviel herumgegoogled, ob es nicht schon ne lösung für das problem gibt ... nix gefunden ... und jetz auch nur durch zufall


    jetz trau ich mich schon gar nimmer, irgendwas fuern vdr zu coden ... weils das dann vielleicht eh schon gibt, nur in google oder vdr-wiki nicht findbar ist ...


    z.B. würd ich gern ein kleines tool schreiben, welches das anlernen von lirc remotes fuer xbmc einfacher macht ... denn die .xml anpasserei geht mir auf den sack ...

    gnaaa ... jetz weiss ich wieso es bei wwoody funktioniert ... ich hab grad gemerkt, dass genau derselbe patch an der selben stelle schon im vdr extension patch mit drin ist .... wollte das nem arbeitskollegen patchen, damit er orf hd gucken kann sobald seine kiste fertig ist, und siehe da: in der codezeile steht schon genau das drin ... gleich mit vdr-1.7.15 verglichen, und dort war es nicht ...


    naja, hatte ein paar minuten lang verschwörungstheorien im kopf, bis er sich endlich erinnert hatte, dass er da ja schon nen patch installiert hatte ...


    also viel arbeit umsonst :evil:

    Moin!


    Nachdem es nachweislich Kanäle gibt, die den Teletext Stream genauso wie Audio- und Video-Streams crypten (im speziellen sind es ORF1 HD und ORF2 HD, von denen ich es sicher weiss), und es auf diesen Kanälen deshalb Probleme gibt (1. Teletext funzt nicht, 2. Kanäle gehn nicht zum gucken per vdr-vnsi-xbmc, weil in der vnsi connection der gecryptete teletext stream mitgeschickt wird, was dann dazu führt, dass xbmc seitig das Bild einfriert), gibts nen simplen Patch von mir, der die Teletext PIDs von gecrypteten Channels auch ans CAM schickt.
    Wenn die Teletext Pid NICHT verschlüsselt ist (was ja bei 99% der Kanäle so ist), sollte das CAM das eigentlich erkennen (nachdem in jedem TS Paket die Scrambling Control Bits liegen), und diesen Stream einfach weiterreichen ... zumindest ist das bei meiner CI-CAM Kombi so ...


    Darum bitte ich all jene, die ein bisschen Zeit und Lust und vor allem ein CAM mit zugehöriger Karte haben, den Patch mal zu testen ... mich interessiert, ob das auf allen CI-CAM Kombis und andren verschlüsselten Kanälen so funzt.


    Ausserdem könnten ja irgendwann mal auch andre Sender auf die Idee kommen, den Teletext auch zu crypten ... nicht nur unser Ösi-Haus-Funk ;)


    Wenn jemand das testen will, bitte dann die Resultate hier reinschreiben, und auch bitte dazuschreiben, welche DVB Karte, welchen CI Slot, welches CAM Modul, und welche Karte ihr habt...


    Danke schonmal im voraus ...



    Gruss,
    Mike

    so ... nach einigem herumtesten bin ich draufgekommen, dass der patch viel einfacher ist, als ich zuerst dachte *g*


    der patch macht nun nix andres, als dass bei einem gecryptetem kanal neben audio und video streams auch fix der teletext stream dem cam zu verfügung gestellt wird ... ein cam modul sollte eigentlich so intelligent sein, zu erkennen, ob ein paket decrypted werden soll, oder nicht (die info steht ja immerhin in jedem einzelnen ts paket drin) ... somit überlass ich die entscheidung, was mit nem teletext packet passieren soll, dem cam ...


    habs getestet mit orf hd (der den teletext ja ganz sicher crypted), fta channels, und mit atv und den andren orf channels, die teletext nicht crypten, audio und video aber sehr wohl verschlüsselt sind ...


    ergebnis: alles funzt ;)


    zumindest bei mir ... könnte ja sein, dass es cam module gibt, die das nicht kapieren (sprich: wenn man ihnen nen stream zum decrypten gibt, tun sie das, egal was im packet header steht)


    drum bin ich auf ein paar tester angewiesen ... beteiligen können sich auch unsere lieben deutschen nachbarn, die orf nicht empfangen können ... mich interessiert hauptsächlich, ob z.B. sky kanäle auf andren CI-CAM kombis als meine laufen


    testablauf: einfach auf nen gecrypteten channel zappen, und den teletext probieren (und dann bitte hier reinschreiben, welches CI, welches CAM, welche Karte benutzt wurden)


    ich häng mal den patch hier rein ... werd ihn zusätzlich auch noch ins developer/patch forum stellen


    viel spass!



    Gruss,
    Mike

    videoman: unter system/video/wiedergabe gibts ne option 'wiederholrate anpassen' oder so ähnlich ... wenn die aktiv ist, dann versucht xbmc anhand des quellmaterials die refresh rate des monitors anzupassen .... damit das aber funktioniert, sollten diese modes in der xorg.conf spezifiziert sein ...

    -= UPDATE =-


    so ... erste erfolge erzielt: habs schonmal geschafft, vdr soweit zu patchen, dass ein zusätzliches flag in der channels.conf anzeigt, ob bei nem kanal der teletext auch entschlüsselt werden soll ... anhand dieser information schicke ich den pids vom teletext auch zum cam modul, und siehe da: orf hd teletext kann nun im frontend der wahl angezeigt werden :D


    allerdings fehlt noch ein teil ... wenn der channel vom vdr upgedatet werden sollte, und sich die teletext pid ändert, dann könnte es troubles geben ... ebenso wenn kanäle editiert, gelöscht etc. werden sollten... also muss ich noch die channel updates patchen, damit grundsätzlich erkannt wird, ob ein kanal den teletext crypted ... hab schon erfolgreich die bits auslesen können, nur muss ich all diese erkenntnisse nun gemeinsam zum laufen kriegen ;)


    paar tage noch, dann gibts nen netten ösi-only patch *fg*



    Gruss,
    Mike

    also wenn deine sat schüssel auf astra zeigt, wirst du wohl nur 50hz material empfangen ...


    problem wirst du erst kriegen, wenn du z.B. mit dem xineliboutput plugin ne 1080p mkv mit 24hz anschaun willst ... dann passt nämlich die 50hz einstellung wieder nicht


    das liebe ich jedenfalls an xbmc ... dass die refresh rate abhängig vom videomaterial immer optimal eingestellt wird ... hauptsächlich aus dem grund bin ich von xineliboutput auf vnsi-xbmc umgestiegen ;)

    mit welcher refresh rate rennt denn der X server ?


    wenn der nämlich z.B. auf 60Hz läuft, und dann 50Hz fernsehbild angezeigt werden soll, dann kann es nur ruckeln ...


    das problem ist halt bei xineliboutput, dass der nicht wie xbmc per xrandr abhängig vom videomaterial die wiederholrate anpasst ...



    Gruss,
    Mike

    Hoi!


    Danke löwe fürs Erstellen des .deb Paketes ;)


    Zur bugtracking Frage: nö, hab das noch nirgends eingetragen ... bin aber grad dabei, nen Patch zu schreiben, der den Teletext auf ORF HD entschlüsselt ... muss mich aber noch ein bisserl mehr in den VDR code einlesen ... damits was ausgereifteres wird ... :D



    Gruss,
    Mike