Jump to content

drdebian

Members
  • Content Count

    53
  • Joined

  • Last visited

Community Reputation

7 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. Sorry to bother you guys, but one of the last updates seems to have broken my Handbrake setup... Automatic conversion no longer works, the log says that the conversion failed. Trying to get at the web UI, I get nothing but an empty screen saying that the "Server disconnected (code: 1006)": According to unRaid, the docker container seems to be running fine: I even removed the image, renamed the folder in appdata to get a fresh start and reinstalled Handbrake... Same result... Looking at the logs I see nothing unusual, apart from these strange errors: The end of the log (while nothing is working) looks like this: Any ideas? EDIT: I reverted back to v1.19.0 and now it all works again, so there's definitely something funky going on with v1.20...
  2. I can gladly report that in my experience, v6.8.2 has greatly improved my SMB speeds. Upgrading two servers also went smoothly, so this version is a win!
  3. There seems to be a minor bug in the docker subsystem though. When updating to a new image, the web UI sometimes "loses connection" to the process and gets stuck, all the while the update either went smoothly or crashed in the background. Anybody else seeing this?
  4. Upgrading the main server also went smoothly, very good procedure. I just wish it hadn't triggered a parity check right after migrating...
  5. Out of the options above, having ZFS would be the most appealing. As for items not on the list, I'd really like to see the inclusion of DVB-drivers into the default kernel.
  6. Alright, my test-server survived the upgrade no sweat... Gonna try upgrading main-server in a few days... Any chance of getting DVB drivers and firmwares into mainstream kernel in the future?
  7. 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?
  8. 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?
  9. 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...
  10. 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...
  11. 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...
  12. 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.
  13. 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!
  14. 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?