Posts by Wild Penguin

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Quote from gda

    Wild Penguin, jeees post is unrelated to your problem. Misunderstandings like this happens if you hijack a thread instead creating a new one.

    Gerald,

    Youre right; my apologies for adding noise!

    I'm not sure why I didn't start a new thread in the first place... however, I did get some help here, and in case I have something to add, I will start a new thread for the issue I'm having.

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Thanks for your replies!

    jeee: I've tried your patch, unfortunately it has no effect on my issue. But thanks anyway!

    For the time being, I've "fixed" it so that I've done the scanning and channel setup without redirect, and hope that it works with redirect for watching / recording.

    After setting up channels, rebooting with redirect, and once I've ran 'gnutv -cammenu', I seem to be able to receive anything via MythTV (or probably other software, too, but that's what I'm currently using); I changed channels back and forth in MythTV last night without issues (on the "redirected" frontend, includeing scrambled channels) - but it may be it is not reliable, and it is certainly dirty and hacky. Only time will tell.

    Also, I've tried dvbv5-scan from v4l utils git, with it I get slightly more informative errors, but the behaviour is consistent with the currently released scan utility - click below if you're interested:

    Display Spoiler

    dvbv5scan creates no channels.conf with the following output, except just once I got a single MUX scanned without errors and it was put in the channels.conf - so there's a succes rate of a few percent. On the other frontend and also on this one when no redirect was in place, it works without issues.

    FWIW I also tried to scan without the CAM in the CI, and the behaviour is exactly the same; I believe that rules out issues with my CAM...

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Ah yes, there's alternatives (other hardware and related software not discussable here).

    But, about this hardware - I've noticed something weird. If I use redirect, the frontend is totally useless, until the CAM menu is accessed once (I use gnutv -cammenu). After that, it's a hit and miss - sometimes the tuning works, sometimes it doesn't, seemingly randomly (with filter timeout messages) - but for different channels each time.

    As I said, it didn't used to be like this sometime last summer.

    Example scan-dvb run: (at point where there's "Network Name: 'TSF_FULL' I've just run "gnutv -cammenu" at another terminal - and adapter_alloc=3, echo "00 01" > redirect; I've moved the CI to another TAB to rule out a broken TAB).

    Display Spoiler

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Quote from thedon

    yes. Have al look at this conversation. I used w_scan but the problems, both, the adapter_alloc and the redirect problem, were very similar.

    Thanks for your reply!

    It seems I've had two errors - one caused by me. adapter_alloc works as expected (has no effect on the functioning of the frontends). The other thread pointed out my error: I've just forgotten to give -d as a parameter for scan-dvb; I can scan the second frontend correctly with:

    Code
    $ scan-dvb -f 1 -d 1 fi-sonera-new

    However, after redirect, the frontend which output I've redirected to the CI/CAM, does not work anymore. It used to work previously without issues (during the last summer / before it!). It seemed that the frontend had became totally unusable, but now I suddenly get some PID's tuned correctly as I speak, while others don't. It seems somewhat random, and increasing the filter timeout does not work (it either tunes without issues quite fastly, within two seconds, or it doesn't tune at all - or, if I understand correctly, it does tune to the initial transponders but the filter does not get any data trough). I need to do some more testing. So, it is actually exactly like your problem in the other thread.

    So, I wouldn't rule out a hardware issue - maybe our hardware has broken in the exact same way. Did you get your issue resolved?

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Hi,

    Sorry for English (I can read German - just barely - but not write it!). I've been following this thread for a while. Also, using my DD Octopus + DVB C/T dual for a while. However, I have a weird problem with using the CAM with the redirect method and adapter_alloc.

    Oh, this is on Gentoo and 64bit . Kernel 3.12.0.

    1st) There's no problem if I don't enable the CAM at all (and use adapter_alloc=0) - I can use both front ends without issue.

    2nd) If I modprobe with adapter_alloc=3 (without echo "AB CD" > redirect!) , I can't tune on the second frontend:

    Display Spoiler


    (the problem here: filter timeout. I get it for every MUX if I let it run, also other software can't use it either. There's nothing in syslog while attempting tuning.)


    But, I can tune on the first frontend (-f 0):

    Display Spoiler


    and, while tuning on the first frontend, I can also tune on the second - but as soon as the first frontend is closed, the second one comes unusable again! (again with the same error as above, nothing in syslog).

    3rd) If I use the redirect method (of course a fresh reboot as per instructions) to try to use the CAM, both frontends become unusable, again with the same error (filter timeout), and nothing in syslog.

    Has anyone had this kind of issue?

    I should probably say, that it used to work in the summer. Since then, at some point it stopped working (I needed to upgrade my Kernel and NVidia drivers), and I haven't come around to fix it, mostly since there's little worth the effort to watch / record on the DVB-C network here. But now, there's a few things I'd like to watch / record...

    My syslog (while initializing the driver):

    Display Spoiler

    And, if I try the redirect method, with this line:

    Display Spoiler
    Code
    # echo "00 02" > /sys/class/ddbridge/ddbridge0/redirect


    I get in syslog:

    Display Spoiler
    Code
    [   10.159936] redirect: 00, 02

    Maybe this is a 64-bit issue? Are there other users using their CAM on a 64bit Kernel?

    Cheers (and thanks for your work with the driver)!