Bugs after upgrade from DVBViewer Media Server 3.3.1.0 to 3.3.2.0

[quentin666]

Hello,

I have recently upgrade to version 3.3.2.0. Since, i'm experiencing some issues (maybe database corruption):

- Some recording titles were corrupted (some had something like "99999", other had "no description" instead). It seems to affects only the WEB streams/channels.

- When I want to schedule a recurring recording, BUT start at a specific date (eg. we are today 2026-06-22 and I want a recurring Mon-Fri to start in the future on the 2026-06-29), it resets it to the closest next date (in my case, 2026-06-23)

 

Please note: It has nothing to do with the self-signed certificate. I have first upgraded DVBViewer Pro 7.3.2.0 and then DVBViewer Media Server 3.3.2.0 without problem bypassing the warning from Microsoft.

 

Best regards,

 

Quentin

 

[Griga]

vor einer Stunde schrieb quentin666:

maybe database corruption

 

For checking this a support.zip would be required.

 

vor einer Stunde schrieb quentin666:

Some recording titles were corrupted (some had something like "99999", other had "no description" instead).

 

No such issue here. Are only recent (3.3.2) recordings affected or old ones too? Where do the corrupted titles appear? Are they still corrupted when returning to 3.3.1?

 

vor einer Stunde schrieb quentin666:

When I want to schedule a recurring recording, BUT start at a specific date (eg. we are today 2026-06-22 and I want a recurring Mon-Fri to start in the future on the 2026-06-29), it resets it to the closest next date (in my case, 2026-06-23)

 

Confirmed. It's due to requests by other users that required to allow back-dating. Don't know if what you want can be somehow combined with what others want... needs to be checked.

 

[quentin666]

 

Hi Griga,

 

Thank you for your quick answer.

 

2 hours ago, Griga said:

For checking this a support.zip would be required.

I've attached it.

 

2 hours ago, Griga said:

No such issue here. Are only recent (3.3.2) recordings affected or old ones too? Where do the corrupted titles appear? Are they still corrupted when returning to 3.3.1?

That was not the recording names, they look fine, but the title entries showed in the Timer section.

Unfortunately I can't take screenshots because I've deleted them and re-created them.

 

2 hours ago, Griga said:

Confirmed. It's due to requests by other users that required to allow back-dating. Don't know if what you want can be somehow combined with what others want... needs to be checked.

I see, so there no easy way to get back to the previous behavior?

 

support.zip

[Griga]

vor 13 Stunden schrieb quentin666:

maybe database corruption

 

I can see no indications of a database corruption in the svcdebug.log.

 

vor 13 Stunden schrieb quentin666:

Some recording titles were corrupted (some had something like "99999", other had "no description" instead). It seems to affects only the WEB streams/channels. (...) That was not the recording names, they look fine, but the title entries showed in the Timer section.

 

I guess you are using an imported EPG for the Web streams. Maybe something was wrong with this data. 

 

Were only recurring recordings affected?

 

vor 9 Stunden schrieb quentin666:

I see, so there no easy way to get back to the previous behavior?

 

 I don't know yet. Has to be investigated.

 

[quentin666]

3 hours ago, Griga said:

I guess you are using an imported EPG for the Web streams. Maybe something was wrong with this data. 

 

Were only recurring recordings affected?

No, the recording title was set manually. In my case that was these two streams:

http://novazz.ice.infomaniak.ch/novazz-128.mp3

https://streaming.nrjaudio.fm/oufdfatx4thg

They were all recurring (I didn't had any one-time scheduled recordings).

 

I found another issue: I record a radio channel 24h a day, scheduled as follow:

Repeat: every day

Start: 00:00

End: 23:59

Follow-up time: 1

It seems to be completely skipped, not recording anymore now.

 

I never had any of these problems with the previous versions, only since I've upgraded to 3.3.2.

I am now considering rolling back to 7.3.1/3.3.1... Is it safe to do, even after that upgrade?

 

Thank you for your support.

[Griga]

vor 7 Stunden schrieb quentin666:

I am now considering rolling back to 7.3.1/3.3.1... Is it safe to do, even after that upgrade?

 

Should work without problems.

 

For investigating the issues I need more time. Are all your timers recurring?

 

[quentin666]

3 hours ago, Griga said:

Should work without problems.

It seems to work. I am now waiting midnight to see if the 24/24 recording restarts as usual.

 

3 hours ago, Griga said:

For investigating the issues I need more time. Are all your timers recurring?

All my timers are recurring.

 

Thanks for investigating!

[Griga]

Am 22.6.2026 um 17:04 schrieb quentin666:

When I want to schedule a recurring recording, BUT start at a specific date (eg. we are today 2026-06-22 and I want a recurring Mon-Fri to start in the future on the 2026-06-29), it resets it to the closest next date (in my case, 2026-06-23)

 

Let's assume today (24.06.) a user creates a recurring timer that is supposed to start a recording each Saturday and Sunday at 22:00. The Media Server automatically sets the next recording date to 27.06. So far ok.

 

Now the user detects that the broadcast in question is also running on Friday, edits the timer and checks Friday in the timer dialog:

• Version 3.3.1 will start no recording next Friday, because the next recording date of a recurring timer is never back-dated. <addition> However, the user could perform back-dating manually in the timer dialog when editing the timer. </addition>
• Version 3.3.2 will start the recording next Friday, because it automatically back-dates recurring timers to the first possible recording date, except if this would trigger immediate execution, because the start time has already passed (otherwise stopping the recording manually before the end time is reached would trigger an immediate restart).

Can you see the problem?

 

Edited June 24 by Griga
Addition

[Griga]

Am 23.6.2026 um 10:36 schrieb quentin666:

I found another issue: I record a radio channel 24h a day, scheduled as follow:

Repeat: every day

Start: 00:00

End: 23:59

Follow-up time: 1

It seems to be completely skipped, not recording anymore now.

 

Confirmed. I've tried it with a timer from 12:10 to 12:09. This is a bug. Probably an unwanted side effect of the "except if this would trigger immediate execution" rule mentioned above. I will look for a fix.

 

[quentin666]

2 hours ago, Griga said:

Let's assume today (24.06.) a user creates a recurring timer that is supposed to start a recording each Saturday and Sunday at 22:00. The Media Server automatically sets the next recording date to 27.06. So far ok.

 

Now the user detects that the broadcast in question is also running on Friday, edits the timer and checks Friday in the timer dialog:

• Version 3.3.1 will start no recording next Friday, because the next recording date of a recurring timer is never back-dated. <addition> However, the user could perform back-dating manually in the timer dialog when editing the timer. </addition>
• Version 3.3.2 will start the recording next Friday, because it automatically back-dates recurring timers to the first possible recording date, except if this would trigger immediate execution, because the start time has already passed (otherwise stopping the recording manually before the end time is reached would trigger an immediate restart).

Can you see the problem?

Yes, I understand the behavior. If it is done intentionally, I could live with it (with still a preference for the old behavior).

 

2 minutes ago, Griga said:

Confirmed. I've tried it with a timer from 12:10 to 12:09. This is a bug. Probably an unwanted side effect of the "except if this would trigger immediate execution" rule mentioned above. I will look for a fix.

I was about asking but just saw you already replied.

Great, thank you very much for your quick investigation!

[Griga]

Am 24.6.2026 um 12:20 schrieb quentin666:

Great, thank you very much for your quick investigation!

 

Here are the results of more extensive investigations:

 

Generally the Media Server and DVBViewer do not support timers with a duration of more than 23:59 hours, obviously resulting from the way they are input in the timer dialog and displayed: start date, start time as hh:mm, end time as hh:mm. Of course both know that in case of a start time greater than the end time, the recording is supposed to stop on the next day. So for a timer with a duration of 23:59 hours something like start time = 12:00, end time = 11:59 has to be entered. The attempt to create a timer for a 24:00 hours recording by entering start time = 12:00, end time = 12:00 yields a timer with a duration of 00:00, which is not executed.

 

However, there are always clever users like you who try to circumvent such limitations, in this very case by using the Follow-Up Time input field for achieving a longer recording duration, thus pushing the Media Server beyond its specifications, so to speak, because this is not explicitely handled in the code. So It may or may not work. In your case, it accidentally works in 3.3.1, but not in 3.3.2 due to slight changes. The "bug" in the Media Server is, that it nonetheless allows such tricks, instead of disabling the Lead / Follow-Up time input fields and forcing a correct and safe solution like using two timers, one with start time 00:00, end time = 12:00, and another one with start time = 12:00, end time = 00:00. The lead / follow-up times are intended for timers created from EPG entries, but not for manually entered timers and not at all for manually entered recurring timers, because with a duration of 23:59 plus a lead / follow-up time they may overlap themselves. This even happens with one extra minute.

 

BTW: A (recurring) timer from 12:10 to 12:09 plus 1 minute follow-up time (see here) neither works in 3.3.1 nor in 3.3.2, because both Media Server versions calculate a duration of 0 minutes due to start time = end time. They don't recognize anymore that the recording is supposed to stop on the next day. Start time = 00:00, end time = 23:59 plus 1 minute follow-up time yields a duration of 24 hours, though, due to the start time being less than the end time and no wrap-around to 00:00 being applied to the end time when the follow-up time is added. The problem in 3.3.2 is rather the calculation of the next recording date. When a recurring 24 hours recording e.g. starting on Monday 00:00 is ending, the Tuesday recording is already overdue, so the Media Server 3.3.2 schedules the next one for Wednesday.

 

So how can this be handled in future? There are two possibilities:

• Design a more restrictive UI, that does not allow users anymore to enter timers for recordings with a duration of more than 23:59 hours.
• Continue to allow such input and try to handle it in the code as far as possible.

However, the second solution may still yield results that are not intended by the user, either because there is an unforeseen collision with other handling in the Media Server, or because it is simply impossible to put it into effect, like recurring 48 hours recordings on each day with a single timer 

 

[quentin666]

Hi Griga,

 

Thanks again for the deeper investigation and explanations on how the system operates.

 

About how to handle this in the future, I have in mind the tick box "All Day" option in Microsoft Outlook which allows creating a 24h event. I guess it would require a bit of redesign and extra code.

At that time I will stay with the 3.3.1, but at some point I might want to upgrade to not stay behind new features or improvements.