Mastermindzh / tidal-hifi

The web version of Tidal running in electron with hifi support thanks to widevine.
Other
918 stars 53 forks source link

JavaScript error on pause #340

Closed aedalzotto closed 4 months ago

aedalzotto commented 4 months ago

Whenever I play or pause the playback, I get "A Javascript error occurred in the main process." This is annoying as the error window pops up, and I can't play the song until I close it. This can happen as well when passing to the next track multiple times.

I've tried to build the package from source, but the error still persists.

image

Mastermindzh commented 4 months ago

I've been working on TIDAL Hi-Fi today and have encountered no such issues, unfortunately. Seems your TIDAL doesn't have an STDOUT connected, how are you launching it?

niraami commented 4 months ago

I'm running into the same issue recently, latest release 5.8.0 via Arch AUR tidal-hifi-bin package. To reproduce, launch tidal from a terminal, and make it a background process (also disown if necessary), like so:

tidal-hifi &
# or
tidal-hifi &!

It should function normally, up until the moment you close the terminal, then the errors will appear on each pause/unpause. The only logs that appear when doing so (while terminal is still open), are these:

Started preventing app suspension with id: 0 
Released inhibitor with id: 0 
Started preventing app suspension with id: 1
Mastermindzh commented 4 months ago

Yeah, now that makes sense.

When you disown and then kill the parent terminal you are removing the STDOUT target that was set by launching tidal-hifi in the first place (the parent terminal). Or, simply put: you're intentionally removing the STDOUT and not redirecting it.

It makes sense that tidal-hifi can't write to the output anymore by then and starts throwing errors as the STDOUT is required. Instead of disowning and then not redirecting the output you should disown with a redirected STDOUT:

tidal-hifi >/dev/null &

That will run it in the background and redirect its STDOUT into the garbage can. The alternative would be hiding logs/errors away with a try catch but that seems nasty.

niraami commented 4 months ago

.desktop files exhibit this same behavior, losing stdout is a normal part of a GUI application. Same goes for flatpak. I don't know in which way you are launching Tidal that you don't receive these errors. I don't believe requiring every possible way of launching Tidal to use pipe to keep alive STDOUT to be correct.

I also don't understand see how suppressing an exception about lack of stdout could be nasty.. you're not checking if stdout exists, so of course it causes an exception. Disabling logging on the first instance of a write error would probably be the correct course of action, but eating the exceptions would be acceptable too i guess.