What have I done with this tread ?
It is now very OT and discusses life the scanner and everything ?
You are all very technical and therefore sort off accept how this works
you "know to much" .
More of the same:
The user perpective is still that ticking some option to change how the
UI presents
>View Tags shows all tags in the file, not just the ones SBS uses. Multiple
>tags i.e. ID3v2 + ID3v1 are combined, and some tag names are changed so they
>are all ID3v2.4 for example.
Oh, thanks for the correction!
I thought that if there were ID3v1 and ID3v2, it would only show ID3v2 tags.
B
On Sep 23, 2010, at 3:51 PM, Phil Meyer wrote:
>> There is already a "View tags" link in the SBS web interface and it's a
>> lot easier to use than looking inside a database for most users.
>>
> I believe this is only tags that SBS understands, and moreover, only the tags
> that the scanner has
>There is already a "View tags" link in the SBS web interface and it's a
>lot easier to use than looking inside a database for most users.
>
I believe this is only tags that SBS understands, and moreover, only the tags
that the scanner has decided to use to produce the music library DB. ie. if
t
MrSinatra;578436 Wrote:
> i think you're missing the point i am making... if i change an option
> in SBS, like the ones you or Jim mentioned, SBS should NOT need to
> rescan the files, new or full; it should simply rebuild the SBS tables
> from the tag cache table (phase 1) or better yet it shou
> On September 23, 2010 Phil Meyer wrote:
>> my understanding is SBS is being redone to "constantly rescan" as the
>> OS informs that changes were made to a file or file table, or something
>> to that effect. assuming thats true, imo, better to use a 'tag cache
>> table' for the benefits inh
>my understanding is SBS is being redone to "constantly rescan" as the
>OS informs that changes were made to a file or file table, or something
>to that effect. assuming thats true, imo, better to use a 'tag cache
>table' for the benefits inherent in it.
In what would would that provide benefits?
>i can not understate how much i HATE IT when SBS kicks off some
>"automatic rescan" or requests one. it shouldn't ever be necessary
>UNLESS data changed, but not when [most] options change.
>
I am really not fond of the automatical rescan at startup (i.e. after first
time installation, or if aut
>The performance isn't an reason as a two stage process probably won't
>speed up incremental rescans, it will only speed up full rescans.
I can't see a full rescan being faster either. It would still need to scan all
files and replace the cache DB or find changed files and apply updates to the
c
>but regardless, this gets back to my point that you should be able to
>change options without needing a rescan at all, or knowing what "type"
>of rescan is needed.
If you change an option that requires a full rescan, I think it automatically
starts the full rescan (I think there's a warning dialo
erland;578431 Wrote:
>
> From a user perspective it shouldn't be important if the system
> performs:
> - A rescan from files
> - A rescan from stage 1 database
> As long as it's fast and gives the correct result, the users will be
> happy.
>
> .
But thats the problem, if one tick in such an op
erland;578431 Wrote:
> Isn't the correct type of rescan performed already today automatically
> by the system if you change one of the options that requires it ?
> I know it at least happens if you change the "separator for multiple
> tag values" setting.
>
> From a user perspective it shouldn't
MrSinatra;578404 Wrote:
> but regardless, this gets back to my point that you should be able to
> change options without needing a rescan at all, or knowing what "type"
> of rescan is needed.
>
Isn't the correct type of rescan performed already today automatically
by the system if you change one
JJZolx;578394 Wrote:
> That's a good question that's been asked before. First, you have to
> figure out how to do it, if it can be done at all.
>
> Looking at it more closely, I see three options that require a full
> wipe and rescan when changed:
>
> 1. Group multi-disc sets
>
> 2. Articles
Philip Meyer;578348 Wrote:
> >i think i like the two phase idea...
> >
> >not having to do a full clear and rescan to change options is to me,
> an
> >absolutely long overdue MUST!
> >
> I think you misunderstand a bit still. If the user changes some
> fundamental options, the database could be
Mnyb;578375 Wrote:
> What beats me as an dB n00b is the fact that the dB created is not "good
> enough" to be used by all optional ways to "see" the collection ?
> Why not create a complete dB that has all info needed ?
That's a good question that's been asked before. First, you have to
figure
What beats me as an dB n00b is the fact that the dB created is not "good
enough" to be used by all optional ways to "see" the collection ?
Why not create a complete dB that has all info needed ?
If an option for example lumps certain albums to one album or something
else, why not have both kind o
>i think i like the two phase idea...
>
>not having to do a full clear and rescan to change options is to me, an
>absolutely long overdue MUST!
>
I think you misunderstand a bit still. If the user changes some fundamental
options, the database could be recreated from a database that holds the raw
i think i like the two phase idea...
not having to do a full clear and rescan to change options is to me, an
absolutely long overdue MUST! ...and also it sounds more safe and
fullproof. any system where you have to try to catch all these so
called "fringe cases" is to me, an inherently flawed sy
>If I remember correctly I think the purpose of a twp phase database was
>to avoid having to do a full rescan when you have changed some setting
>that usually requires it. There was a lot bigger need for this with the
>new schema approach as you may want to re-configure the schema without
>having t
erland;578181 Wrote:
> If I remember correctly I think the purpose of a twp phase database was
> to avoid having to do a full rescan when you have changed some setting
> that usually requires it. There was a lot bigger need for this with the
> new schema approach as you may want to re-configure t
JJZolx;578170 Wrote:
> I'm not convinced that it buys you much either. You still have to deal
> with tracks that change on disk. Unless you completely rebuild the
> main database from scratch using that raw data each time a file
> changes, then you you still have the dependencies and stale rec
Philip Meyer;578161 Wrote:
>
> >I haven't been paying a lot of attention to all of the scanning work
> >you've been doing the last couple releases, so sorry if this is the
> >direction you're headed, but it seems to me that you should have a
> >table in the DB which contains just the absolutely
>I haven't been paying a lot of attention to all of the scanning work
>you've been doing the last couple releases, so sorry if this is the
>direction you're headed, but it seems to me that you should have a
>table in the DB which contains just the absolutely raw tag data. Have
>the new/changed sca
> On September 21, 2010 Andy Grundman wrote:
> Good explanation, this is exactly what 7.6 is doing. :)
I haven't been paying a lot of attention to all of the scanning work
you've been doing the last couple releases, so sorry if this is the
direction you're headed, but it seems to me that you
The discnumber tag creates new albums, this is wanted in multidisk
albums same album name but disc 1 and disc 2 appears as separeta albums
in the db/UI .
My wrongly set discnumber tag created 15 new albums for me .
This is often the case with "new and changed" the old "wrong" albums
linger in th
On Sep 21, 2010, at 1:55 PM, JJZolx wrote:
>
> MrSinatra;578016 Wrote:
>> but thats my question... if you can find all the changed files, then
>> why not rescan the entire file/tag, treat it all as a new record, and
>> then delete the old record as a case where that file no longer exists,
>> (
MrSinatra;578016 Wrote:
> but thats my question... if you can find all the changed files, then
> why not rescan the entire file/tag, treat it all as a new record, and
> then delete the old record as a case where that file no longer exists,
> (at least, not in the same form)?
>
> why try to figu
On Sep 21, 2010, at 8:34 AM, MrSinatra wrote:
>
> andyg;578012 Wrote:
>> Yeah it's not a matter of finding the changed files, it's a matter of
>> checking all dependent things based on the tags in that file, such as
>> artwork, genres, albums, etc. I want to know of the fringe cases so
>> they
Philip Meyer;578009 Wrote:
> I don't see that ever working efficiently; in order to look for
> new/changed files, it would have to calculate the checksum on *every*
> file to see if it was different to the previously calculated checksum.
> Effectively, it would probably be quicker to do a full c
andyg;578012 Wrote:
> Yeah it's not a matter of finding the changed files, it's a matter of
> checking all dependent things based on the tags in that file, such as
> artwork, genres, albums, etc. I want to know of the fringe cases so
> they can try to be solved.
but thats my question... if you
MrSinatra;577979 Wrote:
> Andy, why do you need to be aware of specific fringe cases?
>
> i guess i'm confused... i don't understand why the rescan doesn't
> simply check "last modified" date or something like that (if there is a
> matching existing record of a filepath/filename). if the file
MrSinatra;577985 Wrote:
> two checksums could be done. one for tracking the file if it moves,
> (what they are working on now, the "partial audio" checksum), and one
> for the "whole file" that obviously would incorporate the tag.
I don't see that ever working efficiently; in order to look for
n
Philip Meyer;577980 Wrote:
> >(maybe the md5 checksum could be used instead if you and Erland get
> >that figured out?)
> No, that's calculated on audio data only. Tag changes (and artwork)
> wouldn't change the checksum.
two checksums could be done. one for tracking the file if it moves,
(wha
>(maybe the md5 checksum could be used instead if you and Erland get
>that figured out?)
No, that's calculated on audio data only. Tag changes (and artwork) wouldn't
change the checksum.
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slim
Andy, why do you need to be aware of specific fringe cases?
i guess i'm confused... i don't understand why the rescan doesn't
simply check "last modified" date or something like that (if there is a
matching filepath/filename). if the file has been changed, scan it en
toto as if it is a brand ne
On Sep 19, 2010, at 9:28 AM, Mnyb wrote:
>
> Here is my latest experience .
>
> Added an compilation album to my collection, by a mistake it had not
> spotted that every file had a stray "dicnumber" tag set to different
> values.
>
> So I ended up with 15 albums instead of one, that was perfec
Here is my latest experience .
Added an compilation album to my collection, by a mistake it had not
spotted that every file had a stray "dicnumber" tag set to different
values.
So I ended up with 15 albums instead of one, that was perfectly
understandable.
I corrected the tag and did a scan for
38 matches
Mail list logo
