CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    I tried again with last version from ngene test repository:


    I was now able to compile the zap with the option -enable_dvr_out


    Following results:


    Zitat

    zap -adapter 0 -channels channels.conf -enable_dvr_out "ZDF"


    and in second terminal:

    Zitat

    mplayer /dev/dvb/adapter0/dvr0


    => this plays ZDF nicely. (as it does in mythtv...)


    If I now try to unscramble


    Zitat

    zap -adapter 0 -channels channels.conf -enable_dvr_out "een"

    (also tested with ZDF)

    Zitat

    cat /dev/dvb/adapter0/dvr0 > /dev/dvb/adapter0/sec0


    Zitat

    mplayer /dev/dvb/adapter0/sec0


    this gives the 'error '



    Also "cat ..../sec0 to a file" and playing the file didn't give result.


    any tips? (note: "gnutv -cammenu" accesses the smartcard correctly).


    Walter


    results of "zap":


    Zitat

    Original von walter-
    Also "cat ..../sec0 to a file" and playing the file didn't give result.


    any tips? (note: "gnutv -cammenu" accesses the smartcard correctly).


    Does the recorded file have a size or it is just empty?
    I assume you keep the cat dvr0 > sec0 running in a separate term?


    Zitat

    Original von walter-
    ps: how do I nicely stop "zap"? Ctrl-C is not working....


    That is strange here it terminates on CTRL-C.

    Weitere frage;


    For a free to air station, sending the stream via sec0, should this work?


    So does sec0 know it shouldn't try to unscramble for example ZDF (or is the result of unscrambling the signal the same signal again)?


    Walter

    Zitat

    Original von walter-


    not empty: the file is growing rapidly.


    Then pls try a

    Code
    ffmpeg -i <file>


    on it.


    EDIT: Just abort the recording after 10sec and then run the ffmpeg command on it.

    Zitat

    Original von walter-For a free to air station, sending the stream via sec0, should this work?


    So does sec0 know it shouldn't try to unscramble for example ZDF (or is the result of unscrambling the signal the same signal again)?


    Yes - the CAM will pass-through any unscrambled programs.

    ok some more results using "ZDF"


    => rerunning same commands (of course in different terminals)


    actual result:
    => sending dvr0 to test.ts: gives 'normal' feedback (I think).
    => sinding dvr0 => sec0 => test.ts: gives a "test.ts: Invalid data found when processing input"


    all details below:


    note: in ubuntu 10.10 64bit, I seem to have some issues with the configuration of ffmpeg: I didn't manage to fix them yet. But I don't think this should give any issues.


    Test1:
    => sending dvr0 to test.ts: gives 'normal' ffmpeg results


    terminal1:

    Zitat

    zap -adapter 0 -channels channels.conf -enable_dvr_out "ZDF"


    terminal2:

    Zitat

    cat /dev/dvb/adapter0/dvr0 >test.ts


    results of terminal 3:


    Test2:
    => sending dvr0 => sec0 => test.ts: gives a "test.ts: Invalid data found when processing input" from ffmpeg
    - stop the command from terminal 2:
    terminal 2 start:

    Zitat

    cat /dev/dvb/adapter0/dvr0 > /dev/dvb/adapter0/sec0


    terminal 3:

    Zitat

    cat /dev/dvb/adapter0/sec0 >test.ts


    result of ffmpeg (I left the feedback about the configuration issue)

    I just retest:


    I also got some other output from ffmpeg now.


    I retest 6 times more, I got 2 time the result from this post, 4 times the result "test.ts: Invalid data found when processing input" (as earlier).


    Walter

    Zitat

    Originally posted by digibert
    I'm using the version build from

    Code
    ngene-test2$ hg log | head -n 1
changeset:   15096:9a42d7ae0693


    Maybe you can use this and see if u end up with the same results.


    Hi Digibert,


    => where did you get this version from exactly: I don't see anywhere this version.


    Walter

    Zitat
    Code
    ngene-test2$ hg log | head -n 1
changeset:   15096:9a42d7ae0693


    Maybe you can use this and see if u end up with the same results.


    mmm hg gives me another result (must say I don't really know for what to use the hg command)?


    Zitat

    tv@tv:~/ngene-test2-25f6318da2d0$ hg log | head -n 1
    abort: There is no Mercurial repository here (.hg not found)!


    for the installation I just 'download' the sources and compile them. I don't really connect to the repository.


    Note: I will update to http://linuxtv.org/hg/~endriss/v4l-dvb as Ufo stated in the first post in this thread.


    Walter

    notice:
    before I installed from new repository ubuntu notified me of updates, I install them and after reboot it tries to load the 15fw... (checked and at previous reboot it did load the 18fw)


    Walter

    Zitat

    Original von walter-
    notice:
    before I installed from new repository ubuntu notified me of updates, I install them and after reboot it tries to load the 15fw... (checked and at previous reboot it did load the 18fw)


    The new driver always loads Fw18! Fw15 is used by old drivers only.
    Either an Ubuntu kernel update erased your driver modules or you are using a wrong hg repository.


    CU
    Oliver

    Zitat


    The new driver always loads Fw18! Fw15 is used by old drivers only.
    Either an Ubuntu kernel update erased your driver modules or you are using a wrong hg repository.


    indeed it was the kernel update; but anyway, my problem remained after the update (running latest repository version)


    Walter

    Short side question:

    Zitat

    [ 15.128358] WARNING: You're using an experimental version of the DVB stack. As the driver
    [ 15.128365] is backported to an older kernel, it doesn't offer enough quality for
    ...


    when loading the driver I get this message: Is this just a warning message or is there indeed an issue. An issue in the sence that the code was written for a newer version then the kernel I am running?


    I ran kernel version:

    Zitat

    tv@tv:~$ uname -r
    2.6.35-25-generic-pae


    Walter

    Zitat

    Original von walter-
    Short side question:


    when loading the driver I get this message: Is this just a warning message or is there indeed an issue. An issue in the sence that the code was written for a newer version then the kernel I am running?


    Simply ignore this crap.


    CU
    Oliver

    I had some feedback from Ralph:


    "Using "cat" to write to sec0 is a bad idea. The data written
    to sec0 has to be aligned to TS packets."


    => I am now wondering if this test (cat ../dvr0 > ../sec0 > file.ts) is a good approach.


    If not, any other idea's on how to test?


    Note: at the end there could be many different reasons for
    for my issues (CAM not right version, CAM not compatible, some HW issue, Smartcard not 'activated',....).


    Walter

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden