On Tue, Mar 25, 2014 at 10:30:24AM +0100, Landry Breuil wrote: > On Tue, Mar 25, 2014 at 10:26:55AM +0100, David Coppa wrote: > > On Tue, Mar 25, 2014 at 10:07 AM, Landry Breuil <[email protected]> > > wrote: > > > On Tue, Mar 25, 2014 at 10:01:01AM +0100, David Coppa wrote: > > >> On Tue, Mar 25, 2014 at 9:57 AM, Landry Breuil <[email protected]> > > >> wrote: > > >> > > >> > Fwiw, after moving away the mpdstate file with the weird time entry, > > >> > and > > >> > recreating my playlist, i havent had any issues with 0.18.9. Maybe in > > >> > some > > >> > circumstances mpd gets confused with its internal state (as brian > > >> > linton > > >> > described in his STRs), but so far i've monitored the time: entry in > > >> > the > > >> > current mpdstate file and it stayed at 'normal' values.. > > >> > > >> Nice to hear! > > >> > > >> Then, I'm ok with the update. > > > > > > Well, i'd rather have it properly fixed for a normal upgrade path. > > > Requiring users to remove/lose their state is not nice. > > > > Very simple fix: > > > > into patches/patch-doc_mpdconf_example, change the name of state_file > > from "/var/spool/mpd/mpdstate" to, e.g.: > > "/var/spool/mpd/state" ? > > I dont see how that fixes existing setups. I think digging into the code > and finding out the exacts STRs for the problem, and why it ends up with > that time overflowed value - check if that's really the source of the > problem we're experiencing, and checking that with upstream would be the > next steps .. for the MAINTAINER ;)
So, after playing flawlessly for 3 hours, it stopped again. Looked at the mpdstate file, time had a regular value, but mpd didnt save it yet. pkill -9 mpd to really force-stop it, at that point it saved the mpdstate with time: -2147483648 restarted mpd.. mpc still says the currently played track is the one which was playing before getting stuck. Mpd will only play one track before getting stuck. Kill mpd, set time to 0 in mpdstate, restart mpd. works fine. Landry
