benh wrote:
> Thank you. I think I understand more now.
>
> To restate what you said, the order of operations is to match rules
> based on:
>
> 1. source codec plus player supported codecs, in the order given by the
> player
> 2. It finds first match of source and supported codec and executes,
> rather than finding most specific match, with the following caveats:
> 3. If there is more than one rule matching the source codec plus
> supported codec, the rule matcher will then inspect player model and MAC
> address values
>
Not exactly, the rule matcher builds an array of acceptable matches in
the following text format "$type-$checkFormat-$player-$clientid", where
$type is the source codec and $checkformat is each codec of the HELO
message and $player is player model and $clientid is the MAC. In other
words, if source is 'alc' and codecs in HELO are 'mp3,flc,alc' (note the
order) and player is 'squeezelite' and mac is '00:01:02:03:04:05', it
will do an array with
Code:
--------------------
alc-mp3-squeezelite-00:01:02:03:04:05
alc-mp3-*-00:01:02:03:04:05
alc-mp3-squeezelite-*
alc-mp3-transcode-* (if transcode is enabled)
alc-mp3-*-*
alc-flc-squeezelite-00:01:02:03:04:05
alc-flc-*-00:01:02:03:04:05
alc-flc-squeezelite-*
alc-flc-*-*
alc-flc-transcode-* (if transcode is enabled)
alc-alc-squeezelite-00:01:02:03:04:05
alc-alc-*-00:01:02:03:04:05
alc-alc-squeezelite-*
alc-alc-*-*
alc-alc-transcode-* (if transcode is enabled)
--------------------
There is a detail with forcing transcode that can be placed it at the
top. But then that array is looked in order and compared to "existing
rules" which are made from the combination of custom-convert.conf and
convert.conf (and a few others, but let's put that aside). These
"existing rules" are a hash whose keys are, for example,
"alc-flc-squeezelite-*" - these keys are the first line of every rule
you wrote in the *.conf files, just with a '-' between each token.
So you can see that if the key exists, then the rule matches can now
look at the rule details and see if it works with all the desired perks
(for example the rule might only work for files, or the rule can not
allow goodies likes seeking). If there is no key in the hash, we move to
the next element in the array, if there is a key and all perks are
satisfied, this is our rule!
Now, custom-convert takes precedence because when it populates the
"existing rules" hash, it overwrite any existing key/rule (I've modified
that a bit to allow multiple rules for a given combination, but that's
beyond the scope of this discussion)
>
> 4. If "Prefer native format (decoding on the player) whenever possible"
> is enabled, it will ignore all of the above and just send source codec
> natively, assuming the source codec matches *any* supported player
> codec. If there is not a native match, it will begin to inspect the
> rules.
>
No. When "prefer native...." all what is done is taking the list of
codecs and place the source codec at the top (if it exists of course)!.
As a result, the array of possibilities will start with the source
codec, so your array becomes
Code:
--------------------
alc-alc-squeezelite-00:01:02:03:04:05
alc-alc-*-00:01:02:03:04:05
alc-alc-squeezelite-*
alc-alc-*-*
alc-alc-transcode-* (if transcode is enabled)
alc-mp3-squeezelite-00:01:02:03:04:05
alc-mp3-*-00:01:02:03:04:05
alc-mp3-squeezelite-*
alc-mp3-transcode-* (if transcode is enabled)
alc-mp3-*-*
alc-flc-squeezelite-00:01:02:03:04:05
alc-flc-*-00:01:02:03:04:05
alc-flc-squeezelite-*
alc-flc-*-*
alc-flc-transcode-* (if transcode is enabled)
--------------------
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW,
2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha
WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3
------------------------------------------------------------------------
philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261
View this thread: http://forums.slimdevices.com/showthread.php?t=114534
_______________________________________________
ripping mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/ripping
