Don't worry about the file extension of media file softlink targets #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These came from http://mylefteye.com/sbgfonts originally.
This allows the setting of the shuffle mode to apply for each alarm from the web preferences interface.
A new menu has been added within the Settings->Alarm menu to set the shuffle mode. This is itself a submenu that offers the three choices of shuffle mode.
SlimServer allows softlinks within the media library. In the case of files that are softlinks it currently ensures that both the softlink and the softlink target have file extensions that suggest that the file is a valid media file. This is generally OK, but I'm hoping to keep my music in 'git annex' (http://git-annex.branchable.com) and it replaces media files with a shortcut of the same name to a file held deep in the .git folder structure. The link target, however, loses its file extension. In turn this means SlimServer rejects these media files because it insists that the file extension of both the shortcut and the shortcut target is one of the enabled file extensions. Whist I can see the value in checking the link target in the case where the link points to something totally bogus, it seems unlikely that a shortcut with the correct file extension would be created within the music library hierarchy and that target file wasn't a music file that you intended SlimServer to see. This commit removes the check of the extension of the shortcut target, but keeps the check for normal media files and the shortcut itself.
Cross-fading between tracks with differing sample rates (eg 44.1kHz ripped from CD and 48kHz high quality downloads) appears to cause an alarming burst of white noise at full volume during the cross-fade period. This is the case for my Squeezebox Touch when using the analogue outputs, at least. This modification is an extension of the method used for 'smart' cross-fade and temporarily disables cross-fading when transitioning between tracks with different sample rates. I believe this might fix bug#1884 (http://bugs.slimdevices.com/show_bug.cgi?id=1884) -- a golden oldie that is more than seven years old.
mherger
pushed a commit
that referenced
this pull request
Apr 15, 2021
Use pref to enable/disable use of buffered http requests.
mherger
pushed a commit
that referenced
this pull request
Jun 14, 2021
|
Hey @hickinbottoms - is this still relevant?... or can I close this PR? |
|
Heavens, I'd quite forgotten about it! I don't think it matters to me any longer -- I've been running stock releases for a while and everything is fine for me. Thanks for checking. |
|
Thanks! |
mherger
pushed a commit
that referenced
this pull request
Nov 14, 2023
mherger
pushed a commit
that referenced
this pull request
Dec 28, 2023
Slightly refactor the Genre evaluation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SlimServer allows softlinks within the media library. In the case of files that are softlinks it currently ensures that both the softlink and the softlink target have file extensions that suggest that the file is a valid media file.
This is generally OK, but I'm hoping to keep my music in 'git annex' (http://git-annex.branchable.com) and it replaces media files with a shortcut of the same name to a file held deep in the .git folder structure. The link target, however, loses its file extension. In turn this means SlimServer rejects these media files because it insists that the file extension of both the shortcut and the shortcut target is one of the enabled file extensions.
An example of one of these git annex link beauties is:
"2-03 Act 3_ Scene 1_ To Take Your Hat Off.flac" -> "../../.git/annex/objects/fW/q6/SHA256-s12318592--18ec44dc38f0a1896043dd187bf2633e4242680455083240208b8b9381868fbd/SHA256-s12318592--18ec44dc38f0a1896043dd187bf2633e4242680455083240208b8b9381868fbd"
Whist I can see the value in checking the link target in the case where the link points to something totally bogus, it seems unlikely that a shortcut with the correct file extension would be created within the music library hierarchy and that the link's target wasn't a music file that you intended SlimServer to see.
This commit removes the check of the extension of the shortcut target, but keeps the check for normal media files and the shortcut itself.