Beiträge von MikeDK

  • tuning to the correct device problem

    no problem ;)


    but beware: in order for this to work, the dvb adapter numbering in /dev/dvb/ must always be the same after booting ... i can read that you have a dual card, maybe it is not a problem there ... but if it doesn't work immediately, try switching the numbers or cables

  • tuning to the correct device problem

    sami: yes, if your vdr version is 1.7.13 or higher, you just have to set the information within the diseq.conf file


    basically, the contents for your situation would look like following (if I understand it correctly ;))




    greets,
    Mike

  • tuning to the correct device problem

    i think this behaviour is because of vdr ... as far as I know, there is no possibility in the unpatched vdr, to tell vdr that one receiver is on the first satellite, and another receiver is on the second satellite ... vdr itself only distinguishes between sat, cable, terrestrial ... so if it reads a channel from the channel.conf, it looks if it is e.g. satellite, and then uses the first free dvb-s card ... that means: vdr takes as precondition, that all satellite channels are available on every dvb-s card in the system


    but there is a patch available for such a problem...: channelbinding-patch


    with this patch you can set in the channels.conf, which channels have to be received by which dvb card


    nevertheless, I would suggest you the diseq solution ;)



    greets,
    Mike

  • tuning to the correct device problem

    what about using diseq switches to be able to have both satellites on each cable?


    this would have the benefit that you can record and watch simultaneously on one sat ... and also all other tuning problems would disappear ... but it depends on your lnbs ... you would have to have at least two dual-lnbs for this solution

  • vnsiserver und ORF HD problem

    Mac Gyver: naja, so ca. vor vier jahren konnte ich mit ner terratec dvb-c karte die FTA channels ganz gut empfangen (ging nur mit der terratec, weil die damals als einzige QAM256 beherrschte) ... allerdings eben keine ac3 streams mit dabei :/
    hab mir dann kurzerhand ne sat schüssel ans fenster montiert, und bin seitdem glücklich (zumindest empfangsseitig :D)


    aber seit zwei jahren oder so geht das ja nimmer hab ich gehört ... sogar die FTA channels nun proprietär gecrypted ... sowas tät mich nerven :P

  • vdr teletext decrypten ...

    Ah, super, das ist schonmal ein sehr guter Tip!


    Vielen Dank :D


    hmmm ... ich befürchte zwar, dass ich an der code stelle, wo das adden der gecrypteten pids passiert, noch nicht auf TS packets zugreifen kann ... aber mal sehn... vielleicht kann ich ja irgendein bit in der channels.conf missbrauchen, um das anzuzeigen ... und scan(_s2) patchen, damit das beim scannen geadded wird ... hmhmm ... *grübel*




    Gruss,
    Mike

  • kein anlernmodus mit lirc und seriellem empfänger

    hmm ... yaVDR basiert doch auf debian, oder?


    unter debian selbst muss man, damit man den com port nutzen kann, das paket "setserial" installieren, also:


    Code
    apt-get install setserial


    danach konfen...:


    Code
    dpkg-reconfigure setserial


    ^-- hierbei auf "manual" umstellen


    dann die datei /var/lib/setserial/autoserial.conf editieren, und (fuer com2) die zeile mit


    Code
    /dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test


    in


    Code
    /dev/ttyS1 uart none


    ändern ...


    also bei meinen debian systemen musste ich das immer machen, sonst ging gar nix ...


    (aber bitte nicht hauen, wenn das bei yaVDR eh schon drin ist, hehe)

  • vdr teletext decrypten ...

    Hoi!


    Ich möchte gerne einen VDR-Patch schreiben, der es möglich macht, den Teletext zu entschlüsseln, wenn es sich um einen Kanal handelt, der nicht nur Audio+Video, sondern zusätzlich auch die TPID verschüsselt...


    Zwei Kanäle, die das auf Astra19.2 ganz sicher tun, sind: ORF1 HD und ORF2 HD


    Was ich bisher aus dem VDR code lesen konnte, werden nur Video, Audio, AC3, und ATSC AC3 Streams dekodiert ... also alles, wo in pat.c funktion cPatFilter::Process() "ProcessCaDescriptors = true" gesetzt wird.


    In der ci.c werden ausserdem in den Funktionen cCamSlot::AddChannel() und cCamSlot::CanDecrypt() nur die typen STREAM_TYPE_VIDEO, STREAM_TYPE_AUDIO und STREAM_TYPE_DOLBY behandelt.


    Ich befürchte, das Erweitern der oben genannten Funktionen um den Teletext typ wird wohl nicht ausreichen ... ausserdem stehe ich vor dem Problem, wie ich denn erkennen soll, ob auf einem verschlüsselten Kanal die Teletext pid verschlüsselt wird oder nicht .... denn soweit ich weiss, senden so gut wie alle verschlüsselten Kanäle die tpid UNverschlüsselt ... ORF HD ist da die Ausnahme ...


    Pfusch-mässig könnte ichs lösen, indem ich den channel name hernehme ... das ist so aber schei....., denn der Kanal Name kann sich ja irgendwann ändern...


    Also nun die zwei Fragen:


    1.) Wie erkenne ich, ob die tpid verschlüsselt ist ?


    2.) Auf welche Code Stellen ausser die oben genannten Funktionen muss ich bei diesem Patch achten?



    Ich wäre euch sehr verbunden, wenn Ihr mir bei diesem Problem weiterhelfen könntet ;)



    Gruss,
    Mike

  • vnsiserver und ORF HD problem

    jo, bin mir ziemlich sicher, dass er mitgesendet wird ... sonst würd mein patch nämlich keine wirkung zeigen ;)


    ausserdem gibts in der channels.conf fuer dvb-s(2) bei den orf hd sendern ja ne TPID ... wenn da nix gesendet wird, dann würd da 0 drin stehn ...


    und naja ... die österreichischen cable provider sind recht lasch mit dem mitsenden essentieller streams ... hatte vor etlichen jahren noch cable von upc ... die waren jahrelang nicht imstande, auch nur den DD5.1 stream mitzusenden ...

  • vnsiserver und ORF HD problem

    jo das problem besteht nur bei dvb-s2, nicht bei cable ...


    allerdings ist der patch nur ein workaround, sollte also nicht unbedingt ins vnsi svn eingebaut werden ... weil die stelle, wo ich gepatched hab, eigentlich die falsche ist


    die richtige lösung wäre prinzipiell, den teletext stream von der karte genauso wie audio und video per CAM zu decrypten ... da aber orf hd anscheinend der einzige sender ist, der den teletext verschlüsselt, ist der fehler wohl noch niemandem aufgefallen (ausser ein paar von uns ösis ;))


    ich würd so einen patch ja auch gerne schreiben ... allerdings weiss ich nicht, wo das decrypten von video und audio passiert ...: erst im vdr, oder sogar schon vorher im dvb treiber ... ?!?


    bisher hat mir noch niemand auf diese meine frage geantwortet ... und ganz ohne hilfe möcht ich das nicht machen .... hab keinen bock mich sowohl in den dvb treiber als auch in den vdr code komplett einzulesen *grmpf*



    Gruss,
    Mike

  • Tevii S470 - Keine HD Kanäle

    bei mir ging vdpau erst, als ich es beim aufruf von vdr (in der runvdr bei mir ... hab kein yavdr, also weiss ich nicht, wie es dort aufgerufen wird ...) beim xineliboutput plugin explizit angegeben hab ... sieht bei mir so aus:


    Code
    -P'xineliboutput -l sxfe --video=vdpau -p --post tvtime:method=use_vo_driver --audio=alsa:hdmi -f'



    Gruss,
    Mike

  • kein anlernmodus mit lirc und seriellem empfänger

    Zitat

    Muss die komplett leer sein? ich hab da naemlich die Keyboard eintraege drin.


    nicht nur komplett leer ... die datei darf überhaupt nicht existieren, wenn der lernmodus automatisch kommen soll beim vdr start ... sicher dir halt die vorhandene remote.conf mit den keyboardeinstellungen irgendwohin ... und wenn du die fernbedienung angelernt hast, copy-paste den inhalt der alten datei in die neue hinein ;)

  • Tevii S470 - Keine HD Kanäle

    also ich hab die tevii 470 auch auf nem zotac ion itx f board ... und hier läuft sie super


    die signalstärken, die von femon berichtet werden, stimmen auf manchen karten nicht (wie z.b. auf der 470er), darauf darfst du dich nicht verlassen ;)


    hast du vdpau aktiviert? wenn das nämlich nicht aktiv ist, dann brauchst dich über ruckeln und artefakte auf nem atom board nicht wundern ;)



    Gruss,
    Mike