minimserver stops running

[tarnkappe]

I have minimserver installed on a DS213+. (DSM-Auto-Updates turned off)

Today I was listening to a track (ogg/vorbis) when suddenly the music stopped. The logfile of the minimserver package in DSM just tells me:

Code:

MinimServer 0.8.3 update 57, Copyright (c) 2012-2014 Simon Nash. All rights reserved.
MinimStreamer 0.5.1, Copyright (c) 2012-2015 Simon Nash. All rights reserved.
Java(TM) SE Embedded Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) Embedded Client VM (build 25.0-b70, mixed mode)
Platform default charset is UTF-8
Language setting is 'def'
...
MinimServer[JO] is running
ohNet fatal error: Unhandled exception AssertionFailed at OpenHome/Timer.cpp:253 in thread TimerManager

The crash appeared when opening the naim-App (on iOS) again. It has to reconnect everytime you start it. While I was waiting for the reconnect, the music did stop to play and the naim uniti displayed an "Error".

[simoncn]

(26-01-2015 08:20)tarnkappe Wrote:  I have minimserver installed on a DS213+. (DSM-Auto-Updates turned off)

Today I was listening to a track (ogg/vorbis) when suddenly the music stopped. The logfile of the minimserver package in DSM just tells me:

Code:

MinimServer 0.8.3 update 57, Copyright (c) 2012-2014 Simon Nash. All rights reserved.
MinimStreamer 0.5.1, Copyright (c) 2012-2015 Simon Nash. All rights reserved.
Java(TM) SE Embedded Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) Embedded Client VM (build 25.0-b70, mixed mode)
Platform default charset is UTF-8
Language setting is 'def'
...
MinimServer[JO] is running
ohNet fatal error: Unhandled exception AssertionFailed at OpenHome/Timer.cpp:253 in thread TimerManager

The crash appeared when opening the naim-App (on iOS) again. It has to reconnect everytime you start it. While I was waiting for the reconnect, the music did stop to play and the naim uniti displayed an "Error".

This looks like a bug in the ohNet stack that MinimServer uses to handle the UPnP protocol. Can you reproduce the error by repeating the steps that caused this to happen?

[tarnkappe]

It seems that I cannot reproduce the crash. If I could what should I do (in case the crash would occur e.g. once a week or so)?

Why is ohNet (it is openhome?) involved here? The naim uniti does not support OH?! Can the BubbleUPnp server might be a problem that is running on the NAS, too, proxying minimserver? But I did not use it usually, keeping its playlist empty all the time.

[DavidHB]

(26-01-2015 23:14)tarnkappe Wrote:  Why is ohNet (it is openhome?) involved here? The naim uniti does not support OH?! Can the BubbleUPnp server might be a problem that is running on the NAS, too, proxying minimserver? But I did not use it usually, keeping its playlist empty all the time.

MinimServer uses the ohNet UPnP stack (essentially a set of coded routines and other resources designed to be 'built into' applications) to communicate with other devices. This should not be confused with the OpenHome extensions to the UPnP protocol.

As regards the latter, Simon explained on another thread that

"The OpenHome protocol changes the way the control point and renderer talk to each other. It doesn't change the way the renderer talks to the server. When the renderer is playing music, it is talking to the server to get the music it is playing. This interaction is the same with or without OpenHome."

As I understand Bubble UPnP Server (which I have no need to use), it in effect provides OpenHome compatibility to Control points and devices which lack it. While the presence of Bubble cannot be excluded from consideration, my instinct (subject to Simon's much more informed advice) is that it is not the most likely cause of your problem. If it were, I would expect the crash to be easier to reproduce.

David

[simoncn]

(26-01-2015 23:14)tarnkappe Wrote:  It seems that I cannot reproduce the crash. If I could what should I do (in case the crash would occur e.g. once a week or so)?

To debug this crash, I would need to see an ohNet debug log file covering the period before the crash. To produce this log, you would need to do the following:

1) Set the ohnet.debug property to All-Timer
2) Set the logging level to Debug
3) Run with these settings until the crash occurs. This will create a very large minimserver.log file.
4) After the crash occurs, copy the minimserver.log file to another location before you restart MinimServer
5) Keep the copied minimserver.log file safe and let me know this has happened

Quote:Why is ohNet (it is openhome?) involved here? The naim uniti does not support OH?! Can the BubbleUPnp server might be a problem that is running on the NAS, too, proxying minimserver? But I did not use it usually, keeping its playlist empty all the time.

It's possible that this ohNet bug could be triggered by the use of BubbleUPnP Server. To know what is triggering it, I would need to see the ohNet debug log file.

[tarnkappe]

Is the ohNet debug file always written or has it to be activated? Is it overwritten on each server start or appended to? Where is it located?

[adrian]

I have confirmation that my original issue with the Synology NAS is caused by automatic updates. An automatic update ran today, and immediately afterwords, Minimserver was halted and had to be restarted. So for me it's a satisfactory workaround to have the NAS send me email when it updates so I now to restart minimserver.

[simoncn]

(27-01-2015 14:48)adrian Wrote:  I have confirmation that my original issue with the Synology NAS is caused by automatic updates. An automatic update ran today, and immediately afterwords, Minimserver was halted and had to be restarted. So for me it's a satisfactory workaround to have the NAS send me email when it updates so I now to restart minimserver.

I have emailed Synology twice about this issue but they haven't responded yet.

[simoncn]

(27-01-2015 09:12)tarnkappe Wrote:  Is the ohNet debug file always written or has it to be activated? Is it overwritten on each server start or appended to? Where is it located?

The ohNet debug information is written into the minimserver.log file in the appData subfolder of the MinimServer shared folder.

The minimserver.log file is overwritten each time the MinimServer process is restarted. This is why it is important to copy the minimserver.log file to another location before you restart MinimServer after the crash.

To activate ohNet debug logging, you need to select 'Show log' from the minim icon in MinimWatch and change the logging level to Debug. The ohNet debug messages will not appear in the log window but they will be written to the minimserver.log file.

Please run with this setting for a week or two. If you get the crash again, please save the minimserver.log file and let me know.

[pantau]

(23-01-2015 18:56)simoncn Wrote:  

(23-01-2015 11:26)pantau Wrote:  Hi

I also have the problem of stopping Minimserver on Qnap TS212.

To start it again I've to restart my Qnap NAS.

Regards
Beat

There is a fix in MinimServer 0.8.3 update 57 for a problem that could cause this. You can install MinimServer 0.8.3 on your QNAP by following the instructions on this page.

Hi, made an upgrade ro my NAS. But still have the problem of stopping MinimServer.

Regards