Jump to content

drdebian

Members
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

6 Neutral

About drdebian

  • Rank
    Advanced Member
  • Birthday August 31

Converted

  • Gender
    Male
  • ICQ
    6478117

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Is there any known problem preventing the download of the "missing plugin control" files? EDIT: Turns out that my Pihole DNS blocked the download... Should I feel worried?
  2. I seem to need some help setting up basic authentication. I've created a proxy configuration that works perfectly without authentication, added the user and password to /config/nginx/.htpasswd using the htpasswd command (which I've verified to work using the -v option) and now I only get 403/Forbidden when accessing the proxied page despite entering the correct username/password. I haven't found anything useful in the logs, so I'd be very interested to hear from the experts where to start looking. EDIT: I have now set up another application which is simpler in the proxy configuration, authentication seems to work fine there. So I suspect it's something I had to do in my original proxy configuration that breaks authentication somehow. Here is my proxy configuration: server { listen 443 ssl; listen [::]:443 ssl; server_name tvh.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; location / { # enable the next two lines for http auth auth_basic "Restricted"; auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /login; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_tvheadend 192.168.1.81; proxy_pass http://$upstream_tvheadend:9981; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } The error looks like this: 82.102.24.174 - - [01/Nov/2019:05:26:21 +0100] "GET / HTTP/2.0" 401 179 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0" 82.102.24.174 - test [01/Nov/2019:05:26:25 +0100] "GET / HTTP/2.0" 302 173 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0" 82.102.24.174 - test [01/Nov/2019:05:26:26 +0100] "GET /extjs.html HTTP/2.0" 403 129 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0" 82.102.24.174 - test [01/Nov/2019:05:26:26 +0100] "GET /favicon.ico HTTP/2.0" 403 129 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0" To me this looks like a 401, which gets me redirected somewhere, only to end up at a 403 error it can't seem to get out of. Any ideas?
  3. I see... Right now I copy and paste the command from the cron file to the CLI and trigger it like that... Not very elegant, but it works...
  4. Yes, this is certainly true. I think I'll hold on to both the DVB quad-tuner card as well as the SAT>IP/HDHR solutions... One can never have too many tuners you know...
  5. Glad to be of service! I actually ordered a HDHomeRun in my despair to circumvent the DVB/TVH issue, not being aware of the fantastic minisatip option... Guess I'll be sending that back now...
  6. For those of you who are struggling with TVHeadend messing up in handling a Hauppauge WinTV-QuadHD card, I just came up with a workaround that separates the two and provides great stability: tl;dr: Install minisatip in a separate Docker and let it handle the /dev/dvb instead of TVHeadend, which in turn only gets to use the DVB-C stuff through the SAT>IP network protocol. Problem solved.
  7. Thanks for the info, I'll see what I can do to sort out my issues over here. Honestly I'm quite baffled that this is a TVH issue, since these kernel module messages looked to me like there is something strange going on at the hardware level... EDIT: Turns out it is indeed a TVHeadend issue... As a quick workaround I installed the minisatip Docker image and let it handle /dev/dvb instead of TVHeadend, which now sees the DVB-C tuners through a networked SAT>IP layer provided by minisatip. This way TVH can no longer meddle with my tuner card and it all works like a charm!
  8. Oct 20 04:36:30 Tower kernel: 0x1c0002f0 [ write sol eol count=752 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: risc1: Oct 20 04:36:30 Tower kernel: 0xfc7d9d60 [ INVALID sol eol 22 21 20 19 18 cnt0 resync 12 count=3424 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: risc2: Oct 20 04:36:30 Tower kernel: 0x00000000 [ INVALID count=0 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: risc3: Oct 20 04:36:30 Tower kernel: 0x1c0002f0 [ write sol eol count=752 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: (0x00010670) iq 0: Oct 20 04:36:30 Tower kernel: 0x1c0002f0 [ write sol eol count=752 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq 1: 0xfc7da340 [ arg #1 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq 2: 0x00000000 [ arg #2 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: (0x0001067c) iq 3: Oct 20 04:36:30 Tower kernel: 0x1c0002f0 [ write sol eol count=752 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq 4: 0xfc7da630 [ arg #1 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq 5: 0x00000000 [ arg #2 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: (0x00010688) iq 6: Oct 20 04:36:30 Tower kernel: 0x1c0002f0 [ write sol eol count=752 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq 7: 0xfc7da050 [ arg #1 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq 8: 0x00000000 [ arg #2 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: (0x00010694) iq 9: Oct 20 04:36:30 Tower kernel: 0x00000000 [ INVALID count=0 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: (0x00010698) iq a: Oct 20 04:36:30 Tower kernel: 0x1c0002f0 [ write sol eol count=752 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq b: 0xfc7d9490 [ arg #1 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq c: 0x00000000 [ arg #2 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: (0x000106a4) iq d: Oct 20 04:36:30 Tower kernel: 0x1c0002f0 [ write sol eol count=752 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq e: 0xfc7d9780 [ arg #1 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: iq f: 0x00000000 [ arg #2 ] Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: fifo: 0x00006000 -> 0x7000 Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: ctrl: 0x00010670 -> 0x106d0 Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: ptr1_reg: 0x00006780 Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: ptr2_reg: 0x000108f8 Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: cnt1_reg: 0x0000001a Oct 20 04:36:30 Tower kernel: cx23885: cx23885[1]: cnt2_reg: 0x00000005 I've been having a lot of stability issues lately with my Hauppauge WinTV-QuadHD running on unRAID. Cables are all perfect (getting great SNR/SignalStrength), but it seems like something is still getting in the way on the hardware level (while all other boxes in the house have no trouble using the signal). Scanning for channels/services runs smoothly, all MUXes are reliably found. The problems start when tuning in to channels themselves, sometimes it works instantly, but sometimes I get something along the lines of "2019-10-20 04:36:29.720 linuxdvb: Silicon Labs Si2168 #3 : DVB-C #0 - poll TIMEOUT" in the tvheadend logs... When I go look in /var/log/syslog, I get messages like the ones attached, usually starting with "kernel: cx23885: cx23885[1]: mpeg risc op code error" and a lot of debug details following afterwards. Any ideas?
  9. Ah, that explains it. Thanks for getting back on this so quickly! Guess I'll just have to sit tight and wait it out...
  10. I was wondering if anybody else has the problem that the plugin settings get stuck while "checking available builds" sometimes or throw an error message of not being able to reach the repository (see screenshot)... Any ideas?
  11. Can't wait... In the meantine, Jottacloud's support sent me this: I tried it and it actually works, which is good enough until the updated plugin arrives...
  12. hi there... are there any known issues with the jottacloud remote? I can't seem to authenticate agains the jottacloud servers anymore with rclone... rclone v1.48.0 - os/arch: linux/amd64 - go version: go1.12.6 2019/08/14 06:24:10 Failed to create file system for "ula-jottacloud:": couldn't get account info: failed to get endpoint url: error 401: org.springframework.security.authentication.AuthenticationCredentialsNotFoundException: Token mismatch! (Unauthorized) I tried everything, including removing the remote from the config and recreating it... to no avail... any help welcome!
  13. Yes, exactly. Hardware-accelerated video transcoding goes a long way in making older CPUs a viable option.