I think it's def worthy for LMS to give and keep accurate stats.
How many tracks? Albums? Album artists? Mp3s? M4as? Flacs?
Etc...
How many albums are comps? How many tracks are from comps?
And do the stats LMS displays match the number of audio files scanned?
Seems like a basic and
aubuti wrote:
> The 'dir' (or 'ls') command is cumbersome? Sorry, I don't see a
> compelling, or even interesting, case for the enhancement. But it did
> get me interested enough to check the totals (took all of about two
> dozen keystrokes), and now I'll sleep well tonight. But maybe others
>
An experience this week got me thinking about this thread again. After
adding some new CDs to my collection I noticed that SC 7.4 reported 4876
tracks in my library, but MusicIP reported 4891. After checking with
various OS tools (ls -l in Ubuntu, dir in DOS, Windows Explorer in XP,
etc.) I
aubuti;425074 Wrote:
An experience this week got me thinking about this thread again. After
adding some new CDs to my collection I noticed that SC 7.4 reported 4876
tracks in my library, but MusicIP reported 4891. After checking with
various OS tools (ls -l in Ubuntu, dir in DOS, Windows
Why in the world don't you just fix your tags? You've been at this long
enough to know how important they are.
With most tagging software it should be fairly easy to move id3v1 data
to an id3v2 tag, then delete the id3v1 tag.
--
JJZolx
Jim
Well, I can see where MrSinatra is coming from. So you have 3 bad tags
in 1 titles. If you are vigilant and run the file status and drop
into DOS (DOS!!) and type some DOS commands you can find out you have a
problem. You can then start trawling through your folders until you are
lucky enough
Lesu wrote:
Meanwhile there is a smug piece of software sitting inside of
Squeezecenter, saying 'Well I know which ones they are, but I'm not
telling you!'
It's simply waiting for you to ask. It's called a log file.
specificaly, scanner.log and it can tell you a great many things. You
kdf;320503 Wrote:
Lesu wrote:
Meanwhile there is a smug piece of software sitting inside of
Squeezecenter, saying 'Well I know which ones they are, but I'm not
telling you!'
It's simply waiting for you to ask. It's called a log file.
specificaly, scanner.log and it can tell you a
Lesu wrote:
kdf;320503 Wrote:
Lesu wrote:
Meanwhile there is a smug piece of software sitting inside of
Squeezecenter, saying 'Well I know which ones they are, but I'm not
telling you!'
It's simply waiting for you to ask. It's called a log file.
specificaly,
JJZolx;320484 Wrote:
Why in the world don't you just fix your tags? You've been at this long
enough to know how important they are.
With most tagging software it should be fairly easy to move id3v1 data
to an id3v2 tag, then delete the id3v1 tag.
1. if i knew which albums it was i would.
MrSinatra;320524 Wrote:
do you think examining scanner log files is what the avg user should be
doing? or wouldn't an automated system be better, easier, faster?
Yes it would, but it's a matter of priorities unless you have unlimited
number of development resources.
You could focus on
erland;320536 Wrote:
Yes it would, but it's a matter of priorities unless you have unlimited
number of development resources.
You could focus on implementing fancy new features which 80% of the
users appreciate or you could focus on inconsistency/error handling of
special cases which 5%
MrSinatra;320550 Wrote:
here's a question for you:
in the webUI, go to home - albums, and compare the number of artists
in the summary at the bottom to the number of artists in the settings
status page.
is it the same?
i think that might be a separate bug if not, somehow related to
i just finally finished the bug report after messing up the first one,
:-(
http://bugs.slimdevices.com/show_bug.cgi?id=8764
i hope you will look it over and examine closely my comments and
compare them to the screenshots. i think you will see that there are
some inexplicable things going on,
MrSinatra;320550 Wrote:
i hear what you are saying, but i respectfully disagree. bells and
whistles are not more important than accurately accounting for all the
music one has.
to put it another way, the pinto might have had some great options, but
even if only 5% of them were blowing
Lesu;320508 Wrote:
I'm confused. All the way through this thread no-one has suggested just
looking at the scanner.log file for the files to be identified.
Actually it was suggested way back in 'post #14'
(http://forums.slimdevices.com/showthread.php?t=49429page=2). But for
a lot of readers it
jeffmeh;320560 Wrote:
So some anomalies in the track counts for your music are analagous to a
car exploding? Interesting value judgment :)
well, if ur SB2 was in your pinto...
obviously not my intention, i just think a failure of this magnitude is
important enough to warrant a look even
so i'm getting ready to do the rescan, but i noticed something really
strange! (these observations are being made PRE 'clear and rescan')
in my last post, i showed how the album art summary and dos window
matched and were in disagreement with the settings status tab.
in this post i will paste
So file a bug report already.
(Secondarily... If your library is well tagged, and you don't actually
need to rely on the Guess Tags feature for grabbing tags out of folder
and path names, then jusst clear all the Guess Tags strings. You don't
use them and you don't _want_ SC guessing anything.)
JJZolx;320456 Wrote:
So file a bug report already.
(Secondarily... If your library is well tagged, and you don't actually
need to rely on the Guess Tags feature for grabbing tags out of folder
and path names, then jusst clear all the Guess Tags strings. You don't
use them and you don't
i have now done a clear and rescan with the default values for guess tag
format:
(ARTIST - ALBUM) TRACKNUM - TITLE
/ARTIST/ALBUM/TRACKNUM TITLE
/ARTIST/ALBUM/TRACKNUM. TITLE
these do NOT work for me.
this screenshot shows huge differences in the number of songs between
the status window (which
so now that we're back on the home page, it now reads out 23,694 for
both the SC status and home pages, which is one more than DOS says.
i should also point out that these last two SS have 8 fewer artists
than the first two.
+---+
so, there seems to be a number of bugs here.
first is that the summary of songs and albums changes depending on what
page you're on.
second is they frequently do not agree with what the advanced - status
page has listed.
third for some reason SC seems to be finding one more audio file than i
http://bugs.slimdevices.com/show_bug.cgi?id=8762
--
MrSinatra
www.LION-Radio.org
Using:
Squeezebox2 (primary) / SBR (secondary) / SBC - w/SC 7.1beta - Win XP
Pro SP3 - 3.2ghz / 2gig ram - D-Link DIR-655
MrSinatra's
ok, so here's my first screenshot. this one uses the following strings
in Guess Tag Formats to get these stats:
/ARTIST/ALBUM/ARTIST - TRACKNUM - TITLE
and
/ARTIST/ALBUM/ALBUM - TRACKNUM - ARTIST - TITLE
the other three strings are the default and i left them as 3,4 and 5, i
think they do
anyone? anyone? bueller?
--
MrSinatra
www.LION-Radio.org
Using:
Squeezebox2 (primary) / SBR (secondary) / SBC - w/SC 7.1beta - Win XP
Pro SP3 - 3.2ghz / 2gig ram - D-Link DIR-655
MrSinatra's Profile:
Any help?
i've searched several times and can't find it. (prob my own fault, but
it eludes me)
thx.
--
MrSinatra
www.LION-Radio.org
Using:
Squeezebox2 (primary) / SBR (secondary) / SBC - w/SC 7.1beta - Win XP
Pro SP3 - 3.2ghz / 2gig ram - D-Link DIR-655
Michael,
i can't find the bug either, can u look again? i want to see if its
the same thing i have in mind and vote for it.
thx, -mdw
--
MrSinatra
www.LION-Radio.org
Using:
Squeezebox2 (primary) / SBR (secondary) / SBC - w/SC 7.1beta - Win XP
Pro SP3 - 3.2ghz / 2gig ram - D-Link DIR-655
One thought is couldn't the scanner report unscanable files after a full
scan ?
The report should be so a human can read them.
file blabla.flac with url mnt\music\... etc is not committed to db
check your file/tag.
But i can see complications as SC is guessing tags on filenames and
folder when
Mnyb;316864 Wrote:
The criteria for weeding out a bad file could get complicated.
But if limited to only files that is not included in track count then
I'm positive to idea. It wont solve all problems but it seems not to
complicated to do (says an complete amateur with out any perl skills
One thought is couldn't the scanner report unscanable files after a full
scan ?
We plan on adding this in a later version of SC (sorry, can't find the bug
no.)
Michael
___
discuss mailing list
discuss@lists.slimdevices.com
Mnyb;316864 Wrote:
One thought is couldn't the scanner report unscanable files after a full
scan ?
The report should be so a human can read them.
file blabla.flac with url mnt\music\... etc is not committed to db
check your file/tag.
That report is called the scanner log.
Why not enter
2nd try, this time i'll be brief:
i want a calculation to compare/contrast the stats of the media
library, (specifically number of tracks), to the actual number of audio
files scanned.
if this could only be done in aggregate, so be it, but if it could be
done on a per folder/directory basis
It's not something I've ever felt the need for, even after reading your
explanation of why you think it's needed. And if one wants to check
it's easy to do so using existing OS-level tools (e.g., in Windows: dir
*.flac *.mp3 *.wav /s). Although then if the grand total doesn't match
up it would be
yes, i could use windows to get a file count but thats rather
cumbersome, and as u said it wouldn't help find the discrepancies, it
would just let you know you had some if that number was different from
the SC total songs (tracks) number.
i should be clear that i am requesting a feature here,
The 'dir' (or 'ls') command is cumbersome? Sorry, I don't see a
compelling, or even interesting, case for the enhancement. But it did
get me interested enough to check the totals (took all of about two
dozen keystrokes), and now I'll sleep well tonight. But maybe others
will see the same need you
let me try putting it another way, b/c think ur missing the point, and
i'll post my own screenshots later showing a discrepancy.
this function imo should be part of the normal scan routine, altho if
one wanted to opt out, ok. regardless the point is that with every
scan an automated
No, I'm not missing the point. I see the point and I disagree. Others
might agree with you, but this is starting to seem 'like déjà vu all
over again' (http://forums.slimdevices.com/showthread.php?t=29958) to
me
--
aubuti
what, exactly, do u disagree with?
if i hadn't noticed the best AC/DC album in my ML was missing, which i
noticed purely by dumb luck and b/c it was back in black, i wouldn't
even have known anything was wrong. it led to me filing bug 8380
however, if this function was in place, SC would have
MrSinatra;316842 Wrote:
what, exactly, do u disagree with?
I disagree with the idea that it should be a built-in feature of SC. I
don't think it's necessary. I think it would add to bloat and
complexity -- probably not by a lot, but enough so that the costs
outweigh the meager benefits. I
i appreciate your thoughts, but i guess meager is a matter of POV.
certianly not meager if you're affected. i also expect SC to serve
music, but its hard for it to do it if it can't see it. i don't
consider these issues to be basic filekeeping but rather basic scanning
issues. the files exist
aubuti;316835 Wrote:
The 'dir' (or 'ls') command is cumbersome? Sorry, I don't see a
compelling, or even interesting, case for the enhancement. But it did
get me interested enough to check the totals (took all of about two
dozen keystrokes), and now I'll sleep well tonight. But maybe others
i'll post an enh request in bugzilla once this idea is vetted, if its
worthy, but here's the idea:
for various reasons, SC occassionally has issues locating songs and
putting them into the music library. i have a bug right now about
missing albums when a track has v1 tags but only RG tags on
43 matches
Mail list logo
