Radeox is a rendering engine for an unspecified markup.
Its [website](http://radeox.org/) is dead, the website
of its [authors](http://www.codehaus.org/) is dead too,
its [last commit](https://github.com/codehaus/radeox) was 13 years ago.
It's only used for the welcome and login messages,
as well as comments from users. If we want to have some markup parsing,
we should use something maintained with autoescaping guarantees,
instead of a piece of zombie code prone to $DEITY knows what injections.
Signed-off-by: Andrew DeMaria <lostonamountain@gmail.com>
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>
Date(Long.MAX_VALUE) is 292278994-08-17T07:12:55.807Z on Java 12, and
make Ultrasonic failed to parse.
Signed-off-by: Shen-Ta Hsieh <ibmibmibm.tw@gmail.com>
Until the podcast channel has been updated to provide it with a title, there
is no point to doing any further processing since the directory where episodes
are stored is derived from the title.
While this change is unrelated to #176, it fixes the traceback shown in that
issue.