I accidentally deleted most of my music directory. The database was
still intact. I recovered the music directory by rolling back to a
previous ZFS snapshot and performed a reindex. However, libresonic did
not mark the deleted files as present. Turns out the file timestamp was
unchanged through the ZFS restore, and so libresonic still thought the
last indexing effort was still "good".
This adds the option to ignore file timestamps when scanning files. This
can be helpful in the case of a restore as described above. There might
be a better way to do this, as this was really a quick effort on my part
to fix my own libresonic.
This does not add a UI, just a single property that can be turned on by
editing the lilbresonic.properties file.
@fxthomas suggested this could instead be a query parameter on the
initial issue #359. That would basically move the potential UI to the
scan page. That would be fine, but I could imagine there might be cases
where people want this setting on all the time.
Signed-off-by: Andrew DeMaria <lostonamountain@gmail.com>
Use FileUtil.closeQuietly instead, since it's our reimplemented of this deprecated method.
This change was done automatically via IntelliJ IDEA.
Signed-off-by: Andrew DeMaria <lostonamountain@gmail.com>
This commit is hopefully the final fix on Airsonic's side for #685. It
also fixes#1160, which was caused by temporary workarounds introduced
in #1080 while we were looking for a solution.
The root cause of the issue is the fact that, when we go to the next
track in an Airsonic play queue, we change the media source in the
`ended` event.
In MEJS, this translates as the following two things:
* In Airsonic's 'ended' event, we change the media source (set the `src`
attribute) and call the `load()` method, followed by the `play()`
method.
* The 'ended' event was also used internally by the MEJS player, and
one of these internal uses called the `pause()` method (presumably in
order to make sure that playback was stopped on some media renderers).
Unfortunately, the order in which these events are called depends (in
all modern browsers) on the order in which they are registered.
In our case, the first one is registered inside the `<body>` tag, but
the second one is registered with `$(document).ready(...)`. This means
that the first event handler is called before the second.
This means that, in some cases (when we're unlucky, hence the seemingly
random nature of the bug), `pause()` is called after `load()`
but before the media has finished loading.
Apparently, this causes the `AbortError: The fetching process for the
media resource was aborted by the user agent at the user's request.`
message to appear (which indicates exactly what's described in the last
paragraph), and the playback of the next song is aborted.
This is an attempt to make the Travis CI integration tests more reliable,
and changes from parallel to single forking mode.
This is a temporary measure until cucumber-jvm-parallel-plugin (which is no
longer supported) is ripped out (see #1240)
Signed-off-by: Andrew DeMaria <lostonamountain@gmail.com>
jvoisin
Evan Harris
Andrew DeMaria
tesshucom
benferreri
Jon Borglund
Andrew V. Louis
François-Xavier Thomas
frankdelange
jvoisin
Sid
Celedhrim
Shen-Ta Hsieh