i must add i had to increase the wait time between connecting attemps of the cam module to 1 sec because otherwise the cam module fails to start in time.

alas there's no "safe" way to deal with the various CAM modules out there. Most take a very long time to respond, so the current behaviour is to retry at least 5 times at different intervals (and for the first tries you see that error/warning).

Can you try just with gst-launch ?
I'm not sure what the gnome-dvb-daemon is using/doing, but if they store/update the dvb-channels.conf, you could test it from the command line:

gst-launch-1.0 playbin uri="dvb://<channel_name>"

And provide GST_DEBUG=3,dvb*:6,cam*:6 logs for both an encrypted and unencrypted channel.

how to define the location of the channels file (its in DVBv5 format) so i can use one in the local folder?

can you please provide my the command to use to test this? and any files needed?

this is what i get when running the above command. 
where do i have to put the DVB channel configuration file or how to find out?


gst-launch-1.0 playbin uri="dvb://SYFY"
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstURIDecodeBin:uridecodebin0: Couldn't find DVB channel configuration file
Additional debug info:
gsturidecodebin.c(1404): gen_source_element (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0:
No element accepted URI 'dvb://SYFY'
Setting pipeline to NULL ...
Freeing pipeline ...

i debugged the code and found the path to put the channels file,

i have seen in the code that only zap files will work? or are dvbv5 files also supported? anyway i will test next week to see if i can get the log :p

bbasebin parsechannels.c:69:parse_channels_conf_from_file:<source> parsing '/home/steven/.config/gstreamer-1.0/dvb-channels.conf'

Created attachment 281358 [details]
free to air log BVN

Created attachment 281359 [details]
encrypted channel 'vier' log

Created attachment 281366 [details]
encrypted channel 4 log complete

i think this might be related to the problem:

 if (ioctl (fe_fd, FE_READ_STATUS, &status) ||
+      ioctl (fe_fd, FE_READ_SIGNAL_STRENGTH, &_signal) ||
+      ioctl (fe_fd, FE_READ_SNR, &snr) ||
+      ioctl (fe_fd, FE_READ_BER, &ber) ||
+      ioctl (fe_fd, FE_READ_UNCORRECTED_BLOCKS, &uncorrected_blocks)) {
+    GST_WARNING_OBJECT (src, "Failed to get statistics from the device");
+    return;
+  }

i guess that one (or more) of these fail so it gets the warning and returns, why and how to check i do not know, is htere a way (program) to run these commands (ioctl) manually or to see the return values?

ok i adjusted the code and recompiledit

 its the ioctl (fe_fd, FE_READ_UNCORRECTED_BLOCKS, &uncorrected_blocks) that fails and that makes the method return over and over.

now i do not know where in the driver to find the problem?

or is this not required for the good working of gstreamer? then we can just ingnore the uncorrected blocks and set them to 0 for example if the FE_READ_UNCORRECTED_BLOCKS is not implemented in the driver?

Created attachment 281377 [details]
vier encrypted channel log

excuse me , but the channel info was not correct now it complains only about this:

dvbcam camtransport.c:237:cam_tl_connection_write_tpdu:[00m writing TPDU 82 (CREATE_T_C) connection 1 (size:5)
dvbcam camtransport.c:243:cam_tl_connection_write_tpdu:[00m error witing TPDU (22): Ongeldig argument
dvbcam camtransport.c:370:cam_tl_create_connection:[00m Failed sending initial connection message .. but retrying

i figured out it takes more then 3 seconds for the cam to get in working state:

this was done with also raising the wait time to 1 sec , ill check if the 1 second had influence or not.

see maybe the timeout should be raised to about 5 seconds?

it goes well with the normal retry mode but only 5 seconds total instead of 2.5

but new problem comes up:

dvbcam camapplication.c:334:session_data_cb: unexpected APDU length 20 expected 26

afther that every time this :

dvbcam camtransport.c:500:cam_tl_read_all: error reading TPDU from module: -12
 -->CAM_RETURN_TRANSPORT_TIMEOUT

raising the polling to 1 sec and the read timout to 5 sec changes nothing.

should i try lowering it?

so the error starts with a APDU thats too short? afther that every read fails.

(In reply to comment #6)
> i debugged the code and found the path to put the channels file,
> 
> i have seen in the code that only zap files will work? or are dvbv5 files also
> supported? anyway i will test next week to see if i can get the log :p
> [..]

The channels.conf parsing code can only deal with ZAP formated
files right now. Adding dvbv5 format support is on my TODO but
I haven't get around doing it yet. Also, watch out for GStreamer
having problems parsing your ZAP formatted conf, as there
are multiple variations among scanning tools and while the
order of the parameters seems to be usually the same for DVB-S
the value units change.

(In reply to comment #5)
> this is what i get when running the above command. 
> where do i have to put the DVB channel configuration file or how to find out?
> [..]

You can set the GST_DVB_CHANNELS_CONF env var at launch time
to specify where your channels.conf file is located.

(In reply to comment #10)
> i think this might be related to the problem:
> 
>  if (ioctl (fe_fd, FE_READ_STATUS, &status) ||
> +      ioctl (fe_fd, FE_READ_SIGNAL_STRENGTH, &_signal) ||
> +      ioctl (fe_fd, FE_READ_SNR, &snr) ||
> +      ioctl (fe_fd, FE_READ_BER, &ber) ||
> +      ioctl (fe_fd, FE_READ_UNCORRECTED_BLOCKS, &uncorrected_blocks)) {
> +    GST_WARNING_OBJECT (src, "Failed to get statistics from the device");
> +    return;
> +  }
> 
> i guess that one (or more) of these fail so it gets the warning and returns,
> why and how to check i do not know, is htere a way (program) to run these
> commands (ioctl) manually or to see the return values?

Are you actually getting this warning? I don't see it in your log.

Whatever the case the block you pasted from _output_frontend_stats()
does needs some work. Those ioctl need to wrapped around LOOP_WHILE_EINTR
(as they can a do return EINTR from time to time) for example but
I'm pretty sure this is not the reason for your failure. Don't take
my word for granted though and try commenting out the calls to
gst_dvbsrc_output_frontend_stats () and see for yourself. You should
see no difference.

thanks for your input here but i must say the only error appearing now (afther changing to correct zap file and increasing the times trying) is this one

it goes well with the normal retry mode but only 5 seconds total instead of 2.5

but new problem comes up:

dvbcam camapplication.c:334:session_data_cb: unexpected APDU length 20 expected
26

afther that every time this :

dvbcam camtransport.c:500:cam_tl_read_all: error reading TPDU from module: -12
 -->CAM_RETURN_TRANSPORT_TIMEOUT


so the error starts with a APDU thats too short? afther that every read fails.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/157.