-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maloja randomly goes idle and cannot be used #130
Comments
It seems after a couple backlog scrobbles this also happens.
|
@FoxxMD I need some kind of workaround for this in the meantime. Around a quarter of my scrobbles are lost because of this and I have to manually scrobble. Could this be fixed by a downgrade? |
I also suggest that this error should not cause all scrobbling to stop, because other scrobbles may get through if the error is dropped after a couple retires. |
Unless the whole app is silently crashing there is absolutely a reason why it stops scrobbling and it is logged as the entire scrobble loop is in a try-catch block. Please post the logs before it stops scrobbling so I can better help you.
The error is showstopping. It is occurs in a function that should not have any exceptions thrown and is occurring because the play information is entirely missing. Continuing execution would be useless because data is likely no longer structured as intended and would only serve to cause more log noise as every queued bad-data-scrobble would throw the same exception. There is a reason it is the way it is.
I would recommend at the very least updating to the latest version, 0.6.4. If you are still using flatpak I would also recommend switching to docker installation because:
|
The main reason I haven't been able to do this is because my setup is currently kind of a mess and I don't know how to save logs to a file while they're being printed. EDIT: Just read the other issue, I'll try that.
Yeah, I'm using flatpak. I would imagine Docker takes more memory (I don't have much available besides what I've already allocated) but perhaps I should try it. I have also noticed I've been having some strange issues that generally haven't happened to you or anyone else. I wonder what causes these. I was originally thinking it could be a discrepancy in the system clock, but that would only explain backlog issues, not issues like this one. I'll have to try Docker then. Is it possible to move my cache and configuration (in |
This is the memory footprint for MS with an empty config running on my machine in both flatpak and docker: The top two processes are flatpak -- 86 + 31 = 117mb That doesn't include the memory footprint of docker itself but at least on the application level there is little difference and docker is even lighter than flatpak. To move your configuration copy the entire folder found at P.S. I run docker on multiple raspberry pi4's with 2GB ram. This one has 7 containers running and system, in total, is only using 630MB ram |
Impressive. I don't know why I thought docker used more memory than that. I'm not worried anymore. I'll swap to Docker, How does this command sound: EDIT: I did have to add |
I think this issue is solved. I'll run multi-scrobbler for a bit longer, and also try backlog scrobbling, and close the issue if it's solved. I'm using the develop branch on Docker. |
I haven't had to try backlog scrobbling yet because multi-scrobbler hasn't crashed since I started using docker 😂 |
I added a disclaimer about instability with flatpak installs to the docs.. It's honestly disappointing and a little confusing. Flatpak is supposed to be a "batteries included" environment somewhat (but not the same) as docker where your app should "just work" and be sandboxed with its own dependencies etc...there should not be this much variance in behavior between flatpak and docker. MS is only one process, run by node, with very few system calls or dependencies (just writing log files, if enabled). I don't know what could cause it to crash or have such weird behavior that wouldn't also show up in the docker version. The environment should have very little influence on how it behaves. On top of that Flatpak is infamously hard to debug. It does not easily output a stacktrace or decent debug options for the tools it does provide. |
This morning there were a couple instances of the
The strange part is that these scrobbles did not show up under Queued or Failed Scrobbles. These errors seem to be fewer and further between. Something tells me it has something to do with Unicode artist names and track titles, as I can't find an instance of this happening since I've started Docker with any tracks with exclusively Latin characters. This is |
…ater than 0 #130 Detects track string error thrown reported via #130 (comment)
@duckfromdiscord i may have a fix for that issue. please pull the latest |
Pulled new image, stopped container, removed it, ran again. Will let you know of results. |
Describe the bug
Maloja randomly stops scrobbling.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Maloja target should start when hitting the "Start" button under "Idle."
Logs
It's just this but repeated:
Versions (please complete the following information):
Provide version information for any related sources/clients.
Additional context
Other times, maloja scrobbling doesn't happen at all but there is no error spam.
The text was updated successfully, but these errors were encountered: