The patch is good to go from my pov, if LE maintainers are interested in including in their builds/media_tree packages.
Will be submitting it 'as-is' to the upstream devs early next week.
Posts by jahutchi
-
-
jahutchi I tested your patch with kernel 4.19.14 and I can confirm that it fixed the issue. Thank you!
Great news, thanks for testing.
If u could also post to that effect on the bugzilla thread that'd be ideal; as i reference the bugzilla url in the patch i plan to submit to the upstream devs.
-
smp - I managed to find a couple of days to debug the driver on a 4.19 kernel and develop a patch.
BTW: your hint of unplugging the antenna was extremely useful in debugging.
Any chance you could test the proposed patch I've just posted over on the bugzilla thread:
199323 – DVBSky USB TV tuners do not work since 4.10 due to mutex issues
-
Sounds like same problem many of us have with using this device on recent kernels:
199323 – DVBSky USB TV tuners do not work since 4.10 due to mutex issues
-
No problems, im really just an end user with a little programming experience trying to fix this issue. I have 3 of these devices, so have a vested interest. I'm currently sticking with kernel 4.9 cos of this problem. Really needs one of the upstream devs to fix this.
-
Missing semi-colon - embarrassing school-boy error
Trying again....
-
smp In light of the kernel mutex handoff changes I do wonder whether it'd be wise to adjust the i2c mutex lock in dvbsky.c to be non-interruptible. I can see this is the way it's done in several other of the dvb-usb-v2 drivers (though not all)
I have no idea whether this will make things better or worse, but just thought it may be worth a shot if you have time to test it (find attached).
This builds on my previous patch to use a single mutex for all r/w ops, but also adjusts the i2c mutex lock to be non-interruptible.
Note: I had to give the attachment a .txt extension in order for it to upload.
Other than this I'm all out of ideas.
-
I didn't check dmesg. It failed like it always did with newer kernels - it works for a while but a brief signal disruption randomly triggers the failure. I'm now back to kernel 4.8.16 for everyday use.
Fair enough - I suspect we would have seen a bunch of timeout (-110) errors as previously, but without much indication of exactly why the device has started to timeout.
Just spent a fair amount of time ploughing through the debug traces on bugzilla, and cross-checking some commits that happened during the 4.10 kernel developments.
This one looks suspect since the attach logic in dvbsky.c appears to attempt to modify fe->ops
Does the attached patch to revert this change for the m88ds3103 driver have any effect ?
Unfortunately, I do not currently have an environment upon which to beta test this myself.
-
Sadly, that patch didn't fix the issue. I was able to quickly reproduce it by disconnecting the antenna cable for 10 minutes and trying to tune to a bunch of transponders (when the cable was disconnected). When I reconnected the cable the device was unable to lock the transponders anymore until a reboot.
Do you get any errors in dmesg under these circumstances? Such as the -110 timeout errors seen by others.
-
Nevermind, I did more testing and this issue randomly pops up with any kernel including 4.9.
I've just posted a proposed patch here: 199323 – DVBSky USB TV tuners do not work since 4.10 due to mutex issues
Would be useful to know whether this resolves the issue.
-
I recently tried upgrading to a later 4.9.x kernel (4.9.111), as I'd noticed this fix which seemed related:
kernel/git/stable/linux.git - Linux kernel stable tree
However, I've just hit the problem again (admittedly, it took a couple of weeks to surface)...
I have the following errors in my tvheadend logfile:
And the following messages repeating in dmesg:
Only thing I can do to get the darn thing working again is power cycle.
I am therefore reverting back to kernel 4.9.88.
Since my previous post, it's also worth noting that I've hit the problem (just once) on kernel v4.9.88. This was at a time when my machine was extremely sluggish because a process (tvheadend) ran out of control and chewed all my memory, causing excessive swapping.
I downgraded tvheadend from 4.2.6 -> 4.2.5 where I don't see the memory leakage (reported here: timeshift buffer size problems - Tvheadend). So this could also be related to how busy the machine is at the point you perform the channel switch.
-
jahutchi you need to read the error messages you've helpfully shared. If your DNS is not being updated, then running a resolve script will fix this for you.
On LibreELEC the /etc directory is on a squashfs read-only file system.
Any advice on where the scripts need to go to resolve this issue on a LibreELEC system?
In the meantime I adjusted my network settings to use the Google Dns as this works both on and off the VPN. However, I would prefer to use the DNS of my ISP and VPN provider.
-
I recently seem to have the same DNS issues that others have reported recently. I'm using PIA and have been successfully for the past couple of years. This problem has developed recently though not exactly sure when, and I have automatic updates enabled.
Basically, after connecting to PIA I lose the ability to perform DNS lookups since my DNS settings are still set to that of my ISP rather than the PIA DNS servers.
Here are the logfile entries from openvpn.log when I connect:
Display MoreCode- Wed Jul 4 10:48:05 2018 WARNING: file '/storage/.kodi/addons/service.vpn.manager/PIA/pass.txt' is group or others accessible
- Wed Jul 4 10:48:05 2018 OpenVPN 2.4.0 x86_64-libreelec-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD] built on Apr 15 2018
- Wed Jul 4 10:48:05 2018 library versions: OpenSSL 1.0.2o 27 Mar 2018, LZO 2.09
- Wed Jul 4 10:48:05 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
- Wed Jul 4 10:48:05 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]194.187.249.181:1198
- Wed Jul 4 10:48:05 2018 Socket Buffers: R=[1880000->1880000] S=[1880000->1880000]
- Wed Jul 4 10:48:05 2018 UDP link local: (not bound)
- Wed Jul 4 10:48:05 2018 UDP link remote: [AF_INET]194.187.249.181:1198
- Wed Jul 4 10:48:05 2018 TLS: Initial packet from [AF_INET]194.187.249.181:1198, sid=11215183 2c6b50e5
- Wed Jul 4 10:48:05 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
- Wed Jul 4 10:48:05 2018 VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, [email protected]
- Wed Jul 4 10:48:05 2018 Validating certificate key usage
- Wed Jul 4 10:48:05 2018 ++ Certificate has key usage 00a0, expects 00a0
- Wed Jul 4 10:48:05 2018 VERIFY KU OK
- Wed Jul 4 10:48:05 2018 Validating certificate extended key usage
- Wed Jul 4 10:48:05 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
- Wed Jul 4 10:48:05 2018 VERIFY EKU OK
- Wed Jul 4 10:48:05 2018 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=7ecfe90795b20f017ca8095e02244cd0, name=7ecfe90795b20f017ca8095e02244cd0
- Wed Jul 4 10:48:05 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
- Wed Jul 4 10:48:05 2018 [7ecfe90795b20f017ca8095e02244cd0] Peer Connection Initiated with [AF_INET]194.187.249.181:1198
- Wed Jul 4 10:48:06 2018 SENT CONTROL [7ecfe90795b20f017ca8095e02244cd0]: 'PUSH_REQUEST' (status=1)
- Wed Jul 4 10:48:11 2018 SENT CONTROL [7ecfe90795b20f017ca8095e02244cd0]: 'PUSH_REQUEST' (status=1)
- Wed Jul 4 10:48:11 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,comp-lzo no,route 10.57.10.1,topology net30,ifconfig 10.57.10.6 10.57.10.5,auth-token'
- Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: timers and/or timeouts modified
- Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: compression parms modified
- Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: --ifconfig/up options modified
- Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: route options modified
- Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
- Wed Jul 4 10:48:11 2018 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
- Wed Jul 4 10:48:11 2018 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
- Wed Jul 4 10:48:11 2018 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
- Wed Jul 4 10:48:11 2018 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
- Wed Jul 4 10:48:11 2018 TUN/TAP device tun0 opened
- Wed Jul 4 10:48:11 2018 TUN/TAP TX queue length set to 100
- Wed Jul 4 10:48:11 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
- Wed Jul 4 10:48:11 2018 /sbin/ip link set dev tun0 up mtu 1500
- Wed Jul 4 10:48:11 2018 /sbin/ip addr add dev tun0 local 10.57.10.6 peer 10.57.10.5
- Wed Jul 4 10:48:11 2018 /storage/.kodi/userdata/addon_data/service.vpn.manager/PIA/up.sh tun0 1500 1558 10.57.10.6 10.57.10.5 init
- Wed Jul 4 10:48:12 2018 /sbin/ip route add 194.187.249.181/32 via 192.168.0.1
- Wed Jul 4 10:48:12 2018 /sbin/ip route add 0.0.0.0/1 via 10.57.10.5
- Wed Jul 4 10:48:12 2018 /sbin/ip route add 128.0.0.0/1 via 10.57.10.5
- Wed Jul 4 10:48:12 2018 /sbin/ip route add 10.57.10.1/32 via 10.57.10.5
- Wed Jul 4 10:48:12 2018 Initialization Sequence Completed
I can see the DNS servers in the PUSH reply, but these do not take effect since nslookups are still using my ISPs DNS, and eventually timeout:
After reading this thread I tried activating the "Potential DNS Fix" in the advanced settings but this gave the error:
A DNS fix was not possible. Refer to the Kodi log... which looks like this:
Code- 11:03:37.389 T:140547394086656 NOTICE: VPN Mgr : (common.py) Creating a new APPEND.txt for Private Internet Access to try and fix DNS issues
- 11:03:37.399 T:140547394086656 ERROR: VPN Mgr : (common.py) To attempt a DNS fix, you need to install update-resolv-conf script in /etc/openvpn
- 11:03:37.400 T:140547394086656 ERROR: VPN Mgr : (common.py) Alternatively for systemd enabled installations, install update-systemd-resolved in /etc/openvpn/scripts
- 11:03:37.400 T:140547394086656 ERROR: VPN Mgr : (common.py) After installation of one of the scripts, apply the DNS fix again.
I'm running LibreELEC 8.2.5.
Any help with resolving this would be greatly received and I'll be happy to run further tests to help debug where it's going wrong.
For the time being, as a workaround, I think I will adjust my LE network settings to point at the google DNS servers.
-
Yes I'm on x86_64 custom build currently on kernel 4.9.88.
-
Subscribing to this thread since ive been affected by this too. Im currently running 8.2.5 with a 4.9 kernel (4.9.88) and no problems whatsoever. I did have problems of this nature when using the kernel shipped with 8.2.5.
I also have this problem if i leave the power management options (e.g. S3 suspend on usb), enabled in the BIOS; which was also problem for me in older kernels too.
I hit this problem too a few weeks back after upgrading my kernel to 4.9.92, so i went back to 4.9.88 and all good since.
-
I don't know if the problem would exist if I had specified an external time server.
I've just experienced this same problem over the weekend since the UK clocks went forward 1 hour for BST.
I am running Kodi v17.6 on LibreELEC v 8.2.3 with Tvheadend v4.2.5, with the pvr.hts client on the same machine.
I have not touched the LibreELEC time server settings, so it's using the standard internet time server that ships in the LE settings by default.
On Saturday (when we were on GMT), I was looking ahead in the TVGuide as I wanted to schedule a program that started at 07:30PM on Monday 26th March. However, the TVGuide was showing the program as starting at 06:30PM. I then realised that this was probably because the clocks were changing Saturday night/Sunday morning, so I didn't worry.
However, on Sunday morning, following the Daylight saving changes, I went to look in the TVGuide again and everything was still out by an hour including the programs currently playing. The system time, which is also displayed top-right of the TVGuide had been changed to reflect the DST, so this was correct. However, the TVGuide data was all out by an hour e.g. a show which started at 11AM was actually showing as having started at 10AM, so the timeline which goes vertically down the screen was therefore over whichever program would be playing in 1hr time.
To correct this I went into Kodi Settings -> PVR & Live TV -> General -> Clear data. The database was cleared and refreshed from the Tvheadend backend (as mentioned, this is on the same machine). Following this, all the times were then correct. It would be nice if we didn't have to do this whenever the clocks change.
-
I would test whether the situation is improved in the LE9 builds.
-
Anymore hints? Otherwise I'll try to reinstall everything... And maybe switch to LE9
In that case I would test whether the situation is improved in the LE9 millhouse builds.
I have two MyGica T230 sticks too which work just fine for me under LE 8.2.3 on my Generic machine, though I use DVB-T2 rather than DVB-C which could be the difference.
Presumably, you've only enabled DVB-C in the TVHeadend adapter settings and have not enabled DVB-T?
