Jump to content

Media Server randomly chrashes through HTTPS


SuppaMan

Recommended Posts

Hi!
I'm using the Media Server in a dedicated PC with several cards. I already activated HTTPS access to encrypt communication.
Once a day, however, the server becomes unaccessible through HTTPS but keeps being accessible using normal HTTP. If restarted it will  begin to work again in HTTPS (and HTTP).
Looking in the debug log, there are some errors that can help:
 

30.12.22 22:22:17.285 TDVBWebserver        Server exception EAccessViolation: Zugriffsverletzung bei Adresse 7457E5BA in Modul 'libssl-1_1.dll'. Lesen von Adresse 046889F8
30.12.22 22:22:17.586 TDVBWebserver        Client exception EAccessViolation: Zugriffsverletzung bei Adresse 7779E493 in Modul 'ntdll.dll'. Schreiben von Adresse 00000014
30.12.22 22:22:17.587 TDVBWebserver        Server exception EAccessViolation: Zugriffsverletzung bei Adresse 7779E493 in Modul 'ntdll.dll'. Schreiben von Adresse 00000014

...

30.12.22 23:39:41.205 TDVBWebserver        Client exception EAccessViolation: Zugriffsverletzung bei Adresse 060D30A1. Schreiben von Adresse 060D30A1
30.12.22 23:39:41.205 TDVBWebserver        Client exception EAccessViolation: Zugriffsverletzung bei Adresse 060D30A1. Schreiben von Adresse 060D30A1
30.12.22 23:39:41.205 TDVBWebserver        Client exception EAccessViolation: Zugriffsverletzung bei Adresse 060D30A1. Schreiben von Adresse 060D30A1
30.12.22 23:39:41.205 TDVBWebserver        Client exception EAccessViolation: Zugriffsverletzung bei Adresse 060D30A1. Schreiben von Adresse 060D30A1


Can you help me identify the problem? It it can help, I'll send the entire log in PM.
It's not critical but it would be nice to not send my credential in plain text.
Thank you very much.

 

Link to comment

I've received your log, and I've never seen something like that :blink: The whole log is filled with rapid live stream tuning events using your four DVB-T tuners, every few seconds another tuning, only occasionally interrupted by the access violation errors mentioned above. What kind of usage is this? It looks like people are using DMS clients not for really watching TV, but for zapping all the time.

 

The errors don't occur in the DMS code, but in third party OpenSSL libraries.... I can't find evidence that they are follow-up errors triggered by something going wrong in the DMS. It looks like they only happen under certain timing conditions, more or less randomly. Of course, the frequent tuning events in your usage scenario make it more likely to happen, because for each one an HTTPS connection is closed and a new one established. Hard to reproduce, hard to debug, hard to trace... ;)

 

libcrypto-1_1.dll and libssl-1_1.dll, where the initial access violations occur, are used for HTTPS by the network library, that is used by the DMS for all kinds of network stuff. There are multiple layers involved. It can as well be a bug in OpenSSL, or in the network library, or in the DMS.

 

So, since there are newer versions of the OpenSSL libraries, as I have found out in the meantiime, the first thing I would try is to replace the older versions installed with the DMS, because it's the easiest thing that can be done about it. Please download up-to-date OpenSSL files that are suitable for the DMS from here, stop the DMS, make a backup of the old libcrypto-1_1.dll, libssl-1_1.dll and openssl.exe (in case it gets worse with the new ones), copy the new files from openssl-1.1.1s-win32.zip to the DVBViewer/DMS program directory, restart the DMS and see what happens...

 

Link to comment

Thanks for the response. I did not explained the whole use I make of the software: I'm using it to make a sample of a channel every few minutes (but since a new full cycle of samples begins before the others end, it results in calls to the service every few seconds, and occasionally it can't return the stream because of not tuner available). So that's the right behaviour I want to achieve (as you can see in the logs).

I will try to upgrade the libraries then I'll report :)

Link to comment

Unfortunately, upgrading the library did not make any changes: after some time the service becomes again unaccessible through HTTPS. A new error appears in the log in addition to the old one. I sent you a new support.zip in PM if it can help.
Guess for now I'll stick with HTTP...

Link to comment

Please also update to the latest DMS version 3.2.3 (you are using 3.2.2). It contains a fix for bad error handling in the network library, which may be related to the issue you are experiencing.

 

All access violations reported in the log are not happening in the DMS code, but are first handled by the network library, which notifies the DMS of the event. Unfortunately I have no means to reproduce the issue under debugger control, because your usage scenario is quite special. I would first have to invent something that simulates all the rapid HTTPS live stream requests and the tuning. Which client(s) are you using?

 

The release notes of newer network library versions (beginning with 8.63, see here) indicate quite a lot of HTTPS improvements (look for SSL/TLS). However, updating the network library is a major change requiring many adjustments in the DMS and network library code plus subsequent tests. It usually takes several days (at least). It will be done sooner or later, but I can't tell when a first test version will be available. It also depends on what else has to be done.

 

So I can see no short term solution for your problem now.

 

Link to comment

The rapid calls are made mainly with FFmpeg, but every 2 hours other call occurs to the EPG API (using Python request library)

Just updated the DMS to the latest version... I'll report the results. For now it seems stable 🤞

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...