Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So I have a recurring issue:

1) I'll have a power blip.
2) About half of my machines are on some kind of UPS, but a few pi's and some network infrastructure aren't on a UPS, so when the power blips, the pis turn off and restart and my network starts trying to reinitialize and reassemble itself.
3) The pis boot, jriver tries to start and cannot reach the server, because the pi's have come up faster than the network.  JRiver then throws up the "can't reach remote library" error dialog box and stays there indefinitely.  I don't use all of these pis every day (some are in remote rooms, or rooms where listening is very occasional), so I often find that they're not working when I try to use them because some power blip that happened a week or two ago when I wasn't home put them in that stuck state.

I haven't been able to figure out a way to programmatically detect the existence of that error box.  Obviously I can vnc into all of these pis more regularly to police that, but that's time consuming. 

To improve the functioning of JRiver as an appliance, it would be nice if JRiver would do one of two things when it enters that "stuck" state, either:
1) Retry automatically at long intervals, i.e. every five or ten minutes, or
2) Exit the program if the dialog sits untouched for some amount of time (ten minutes, thirty minutes, whatever).

Either would work great because periodic retries would eventually result in a connection, and it's trivial to script JRiver to restart once it's no longer running.

I guess I could just have them reboot every night or something.  That would at least make the issue less frequent as some number of stuck conditions would get swept away automatically.

EDIT: it occurs to me this isn't necessarily linux specific so feel free to move it to somewhere you think might fit better.  I was just thinking about it in the context of raspberry pi's.

[mattkhan]

this feels like the same problem as the one where a client doesn't keep the server awake (e.g. server goes to sleep, client stays awake, client won't wake the server up without restarting) which definitely isn't linux specific, +1 to fixing this anyway as it's the reason I have to leave my server on 24/7

[bob]

I see a few ways to address this:
One, when MC is run with the /mediaserver option it can exit if it can't reach the library server.
On an Id, we try to restart MC once a minute if it's not running for any reason. This would eventually succeed when the server comes back up.

Second, when MC starts on that client box, it could do retries to connect to the library server every 30 seconds or so and eventually timeout say after 10 retries and exit. Same scenario for restart.

Third, MC could try infinitely to reconnect every 30 seconds or so.

Not sure which is the best method...

[mwillems]

I see a few ways to address this:
One, when MC is run with the /mediaserver option it can exit if it can't reach the library server.
On an Id, we try to restart MC once a minute if it's not running for any reason. This would eventually succeed when the server comes back up.

Second, when MC starts on that client box, it could do retries to connect to the library server every 30 seconds or so and eventually timeout say after 10 retries and exit. Same scenario for restart.

Third, MC could try infinitely to reconnect every 30 seconds or so.

Not sure which is the best method...

I think method three (or maybe some variant on method two) is probably the best method in my opinion.  If it retries periodically for at least a while that's a much greater chance for the system to be "self-healing" for the average user.

I have an auto-restart on exit scripted as well (in the systemd services) so exiting is no skin off my nose if that's where we land, but I think for the normal person using MC in a sever/client setup, the fewer situations in which a client is unreachable via network, exits spontaneously, or has an error box showing when you try to use it, the better.