Broadly speaking this is a common requirement in different environments, because many music players require a "rescan" even if its only tags that have changed.
Jim, you're probably not missing something. The automation settings are in the settings page, where automation is possible.
I tend to take the approach of making a rule manual first, then after some testing and iteration, make it (potentially) automatic.
If there's a specific rule you think can be automated, add that as a separate idea.
I've had similar comments that it gets difficult to work with multiple track name fixes on the same album page, because compliance re-assessment occurs after each fix.
The Inbox might be closer to what you want, although it uses the same button-to-describe-fix approach. Thoughts on that?
Nice idea - maybe on the album detail page too.
That's an interesting subtlety any implementation would have to cater for...
> am I missing something?
Only a time machine ;-)
Seriously, this is on the roadmap, it clearly has a lot of support.
It appends a suffix number, e.g. _2, _3 etc...
Jake, if you have the time it would be interesting to know if the fpcalc tool (the same fingerprinter bliss uses) generates the same fingerprint for the tapes and the other recordings: https://acoustid.org/chromaprint . If you get the chance, run fpcalc from the command line giving the music file as an argument. Copy and paste the results and send to email@example.com ... if you don't get the time, don't worry ;)
I remain to be convinced!
When using the release-canonical artist name, it would be just on a release by release basis. Maybe an artist released different albums with slightly different names!
I was referring to your comments on other ideas such as http://ideas.blisshq.com/forums/21939-bliss/suggestions/4461522-albums-and-artists-fusion
Agree about artist names being a difficult problem in isolation (we've seen that with the existing canonical artist name rule) but maybe what is easier is, when the release can be identified, the canonical artist *for the release* is used.
I can see how this would help; in some ways it might be a short term fix to help you find these artists until a rule can be developed?
Ok, so update on this is that I think to an extent release canonicalisation fixes this - if albums are split or duplicated with slightly different names, the album name correction rule should find them and suggest changing the names to the same thing (this would occur separately).
But I think this idea should remain open, basically because it could work around not being able to find the data for a release.
I see this more as a UI feature right now, rather than a rule. For example, being able to multi select as Bruno said to combine albums.
Yeah, there's definitely an aspect of this where you'd want to just fix it in your library, not necessarily use external definitions of canon.
Would canonicalisation fix this? If the "correct" name for the release was found and both albums were changed to match this (maybe one doesn't need to be changed) wouldn't that work?
I ask because we already have this for artists: http://www.blisshq.com/music-library-management-blog/2012/02/28/errant-artist-names/
I posted a way of automatically setting file ownership using inotify: https://www.blisshq.com/music-library-management-blog/2017/06/06/changing-permissions/
Took me a while to notice this one but here I am...
As bliss is written on Java 6, which has poor support for file permissions, this is difficult to do. If/when I move to Java 7, this will become much easier.
Yep, I think we'll end up going this way eventually. Did you see http://ideas.blisshq.com/forums/21939-bliss/suggestions/5490000-individual-rulesets-for-different-locations ?
The idea would be to convert all files from any format to one specific format, ignoring (but including) files already in that format.
Interesting comment. You don't think maintaining different versions of a file is a form of management?
The idea was also partly inspired by mp3fs ( http://mp3fs.sourceforge.net/ ) although obviously without the FUSE filesystem having the mirror leads to more duplication, so it's not quite as elegant.
Very true, but then it's a similar situation elsewhere - depending on your player different fields can be interpreted in different ways.
Yeah, that's a concern when changing existing fields, but if we combine that with online data, where the date is formatted in a consistent way, we can work around that.
Also, more generally, support for formatting date/time fields. So you could specify:
As your format, so only years are stored. Or:
For a full date in the common US format.
Not sure how the date should be filled when there isn't enough information... maybe simply omitting the more specific parts would be fine.
Are you saying you want the subtitles in the album name, or just that bliss is matching to the incorrect release?
One thing that might be useful is the ability to choose a subset of the Linked Releases to use.
Yes, good example.
Just wanted to make a note to myself...
Rather than specific "ignore" functionality this should work by implementing "selectors". Create a new selector for this specific album, with a slightly-changed ruleset.
This would be preferable, because selectors are a more powerful, less specific implementation and it should mean less code overall.
Yes, although the way I look at it is having a "selector" to which rules can be applied, e.g.
select all albums where genre = "christmas" => [specific rules]
I just have a natural aversion to conditional statements :D
Nice idea! Might need to add that as a separate idea, though... I'll close this once "ignore" is implemented.
Good idea on the button.
For the colours, do you mean the text "Album name", "Genre" etc should be coloured differently to differentiate?
I just added correctness checking for compilation. This works in a different way to other correctness checking, in that if the setting is absent, we always look at linked releases anyway. If the linked releases say that this is definitely a compilation, a fix is suggested to change it so.
This is a different solution to that laid out above, which is more of a "derived tag" solution, so I'll keep this open as it might have been that which people have voted for.
Thought about this for a long time, thanks for suggesting it!
Good point about not having enough time - hadn't thought of that...
You can certainly change the folder that bliss monitors. That's a workaround I've heard from a few people: a 'staging' folder that people copy files into and out of that bliss monitors.
Fair enough Jeff. Actually, this is where I see the new activity stream work going (see http://www.flickr.com/photos/dan-gravell/5915273252/in/photostream ). I'm thinking the first time someone uses bliss, all the upcoming work is shown here for confirmation. Then, there's a 'latch' to automate all the actions, if that's what you want.
Obviously bliss's history is as a fully automatic tool - that's not something I would want to lose.
Thanks Jon, I've had a few questions about this. The other thing to make consistent is the number of lines of album names - I'd have to shrink the title font, and truncate overly long names.
Definitely agree, just something I haven't implemented yet. I'll change the title of the idea, if that's ok.
There is an opt-in/opt-out option - it should show as a blue bar at the bottom of the page. Do/did you not see that?
Jason Schafer has written up some instructions on setting up an NGINX proxy in Windows, and I've adapted his instructions for Linux/OS X: https://www.blisshq.com/music-library-management-blog/2017/03/07/setting-up-bliss-authentication/
Ok, well I changed the idea to be a first, simple small step to introduce username/password authentication.
Ok, well I prefer small steps, so can we change this idea to "Authenticated access to bliss", specifying minimum of HTTP basic authentication and the fact that there is only one level of authorisation: access? There would be no finer grained access control rules for this idea, that can come later.
I'm interested in the car PC project, let me know if I can be of any further help. I've had some previous contact from people who have installed bliss on ARM architectures.
Thanks for this. What would you say is the absolute minimum first step? Adding a username/password challenge to bliss? Would you actually use this, and what are the reasons for using a username/password challenge?
It depends what you mean by "bring the user to the location in the file system where the represented album exists".
It's hard to just pop up an instance of Windows Explorer pointing at that folder.
Chrome won't even let you open file:// links *at all* when the original content is served over http.
However, if you just want to see the locations listed so you could copy and paste into Explorer, that's easy.
I like the intent of this idea. There's a fundamental problem though, in that bliss is designed as much to work on servers as it is a local desktop or laptop. If bliss is installed on a different computer you cannot open up the OS's file navigator to that location.
This is why the 'Browse' button, when choosing your music library, doesn't show the standard OS navigator, it shows the file system for the server that bliss is installed on.
If bliss listed the actual files within the Web UI, would that be ok? Were there things you know could not be achieved by doing this? I guess I'm asking what sort of things you would do with the OS navigator.
I guess an ability to "skin" the interface could be something... if you know CSS you can probably do something yourself with a browser plugin to override the CSS.