content type ALC is apple lossless (as of change 9103)
content type MOV is for audio/x-quicktime-movie,audio/x-m4a.

Strings for MOV and ALC already reflect this.

Are you seeing evidence that the content type is not being set correctly?

(In reply to comment #1)
> 
> Are you seeing evidence that the content type is not being set correctly?
> 
What I am seeing is that ALAC files are in the SqueezeCenter database as content_type mov once they are scanned.  They play just fine through.

I don't have any lossless files, so I have no experience.  
What file type shows in songinfo?
What command is executed on playback? (player.source=debug)

it seems that alc type exists only at playback time.  From Player::TranscodingHelper::getConvertCommand():

	# Switch Apple Lossless files from a CT of 'mov' to 'alc' for
	# conversion purposes, so we can use 'alac' if it's available.
	# 
	# Bug: 2095
	if ($type eq 'mov' && blessed($track) && $track->lossless) {

		$log->debug("Track is alac - updating type!");

		$type = 'alc';
	}

Do we want songinfo to show alc type?  trackinfo, jive trackinfo, etc?
Or, mov type could go back to including lossless.

I wanted to mention related bug 8374 which turned out to be a dupe of bug 3174.

Adding Dean for comment.

I suspect that this detection should happen at scan time and not playback time, i.e. the scanner should detect that it's apple lossless and add it to the db as such.

It's not really a localization issue (i.e. different languages).

Created attachment 3439 [details]
possible fix

I don't have any alc files to test with, but this seems to be the way to deal with the CT at scan time.  Initially, the suffix will tag it with mov type, but then scan should correct it to alc.  New and changed scans will have it as type alc, which is why I set to tagFormatClass to point alc to Formats::Movie as well.

Steven did you ever check KDF's patch?

If it works okay, please cc Michael (as main SC developer) and ask KDF to go ahead and commit it!

Steven to check this out when he gets back tomorrow.  If there are still issues, we should probably push this change off to 7.3

The possible fix provided by KDF seems to solve part of the problem.

With the fix applied I now see Apple Lossless files reported as "Apple Lossless" by SqueezeCenter after doing a rescan.  A minor issue is if I navigate to an Apple Lossless file that has been added to the library after the last scan using the music folder function SqueezeCenter will still display "Apple AAC or Movie File" until a newer scan has been performed.

I also wanted to note that I think the string "Apple AAC or Movie File" should be changed to "AAC or Movie File" once this is successfully implemented.  I still have not been able to figure out when the string changed from "Apple Lossless, AAC or Movie File" to "Apple AAC or Movie File"  Perhaps this should be filed as a separate bug?

change 22217 - checked kdf's patch in. Steven - could you please attach a small alac file to test the rescan issue?

Don't know about the string issue. IMHO it's correct, as ALAC has its own string. Doesn't need to be changed, does it?

Punting post 7.2 as I won't be able to fix this in time (if at all).

Oops, sorry, didn't want to punt this one. But as Steven said the main issue was fixed with this change this should be ok in 7.3. Ok?

Created attachment 3708 [details]
Very small Apple Lossless file for testing

(In reply to comment #11)
> Don't know about the string issue. IMHO it's correct, as ALAC has its own
> string. Doesn't need to be changed, does it?

Michael, IMHO the sting that should be changed is for the mov file type not the alc file type.  So if this change is implemented the string for mov should be "AAC or Movie File"  If this change is not implemented the string should be "Apple Lossless, AAC or Movie File"  The current sting "Apple AAC or Movie FIle" does not make sense since AAC files are not inherently Apple.

Noticing the string change for mov files is what prompted me to open this bug in the first place ;)

change 22736 - we have to update the local filetype cache, as the real format is only read after a first (inaccurate) estimation based on the file's extension

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Reduce number of active targets for SC