If Nuvio 0.3.2 opens and then sits there loading sources forever, never playing anything — this is that bug, and it is fixed.
Symptoms: the app launches straight into resolving sources for something you were watching, the spinner never stops, nothing plays, and it does the same thing every time you start it.
Fix it in two steps
1. Break the loop. Quit Nuvio, then run:
rm ~/.config/nuvio/nuvio_resume_prompt.properties
Nuvio will start normally again. You need this first — while it is looping, the app never finishes starting, so it can never check for updates.
2. Update to v0.3.3. Settings → About → Check for updates, or download it from the release page. Without this step the hang can come back.
Deleting that file only clears the resume where you left off prompt. It is not your watch history, library, addons or settings, and none of those are touched.
Am I affected?
Only if you are on 0.3.2. Check Settings → About.
0.2.x and the withdrawn 0.3.0/0.3.1 alphas do not have this bug. It is most likely to hit you if you closed the app while a video was playing, because Nuvio then tries to resume that item on the next launch — which is the exact path that gets stuck.
What went wrong
0.3.2 changed auto-play to hold a torrent back while its debrid cache check was still running, so it would not start a slow local download for something debrid was about to serve from cache.
The check for is this still in flight treated a stream that never received a cache status at all as permanently pending rather than briefly pending. The screen that waits for auto-play only gives up when nothing is pending, and there was no timeout out of it — so it waited forever.
0.3.3 reverts that change. Auto-play behaves exactly as it did in 0.2.3.1 and every release before 0.3.2. That is the only change in 0.3.3.
Sorry
This was a self-inflicted regression, shipped in a release that was meant to be a safe stable build, and it went out because a change was made to satisfy tests that had never actually been run. That gap has been closed, and an auto-play case is being added to the pre-release verification protocol so this specific path gets exercised on a real machine before shipping in future.
If deleting the file above does not fix it for you, please comment here with your version from Settings → About and what you see — that would mean something else is going on and I would want to know.
If Nuvio 0.3.2 opens and then sits there loading sources forever, never playing anything — this is that bug, and it is fixed.
Symptoms: the app launches straight into resolving sources for something you were watching, the spinner never stops, nothing plays, and it does the same thing every time you start it.
Fix it in two steps
1. Break the loop. Quit Nuvio, then run:
rm ~/.config/nuvio/nuvio_resume_prompt.propertiesNuvio will start normally again. You need this first — while it is looping, the app never finishes starting, so it can never check for updates.
2. Update to v0.3.3. Settings → About → Check for updates, or download it from the release page. Without this step the hang can come back.
Deleting that file only clears the resume where you left off prompt. It is not your watch history, library, addons or settings, and none of those are touched.
Am I affected?
Only if you are on 0.3.2. Check Settings → About.
0.2.x and the withdrawn 0.3.0/0.3.1 alphas do not have this bug. It is most likely to hit you if you closed the app while a video was playing, because Nuvio then tries to resume that item on the next launch — which is the exact path that gets stuck.
What went wrong
0.3.2 changed auto-play to hold a torrent back while its debrid cache check was still running, so it would not start a slow local download for something debrid was about to serve from cache.
The check for is this still in flight treated a stream that never received a cache status at all as permanently pending rather than briefly pending. The screen that waits for auto-play only gives up when nothing is pending, and there was no timeout out of it — so it waited forever.
0.3.3 reverts that change. Auto-play behaves exactly as it did in 0.2.3.1 and every release before 0.3.2. That is the only change in 0.3.3.
Sorry
This was a self-inflicted regression, shipped in a release that was meant to be a safe stable build, and it went out because a change was made to satisfy tests that had never actually been run. That gap has been closed, and an auto-play case is being added to the pre-release verification protocol so this specific path gets exercised on a real machine before shipping in future.
If deleting the file above does not fix it for you, please comment here with your version from Settings → About and what you see — that would mean something else is going on and I would want to know.