philippe_44 wrote: > 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. > It's normally built once when LMS starts. > > 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 overwrites any existing key/rule that other > .conf files have set before (I've modified that a bit to allow > multiple rules for a given combination, but that's beyond the scope of > this discussion) > > 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) > -------------------- > >
This is *fantastic*. Thanks. Your explanation makes the process very clear. Understanding that the convert.conf entries are really hash key/value pairs and how they are ordered was, for me, the critical bit. Knowing that the order is defined by the sequence of codecs as returned by the player was also, er, key. My initial roadblock was thinking of this as more like a firewall ruleset when it doesn't act that way at all. ------------------------------------------------------------------------ benh's Profile: http://forums.slimdevices.com/member.php?userid=6732 View this thread: http://forums.slimdevices.com/showthread.php?t=114534 _______________________________________________ ripping mailing list ripping@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/ripping
