Precompiled binary ignores -m flag

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start two instances of SL:
squeezelite-i386 -s localhost -o plughw:CARD=Intel,DEV=0 -d all info -f 
/var/log/squeezelite-1.log -m 00:04:20:F2:00:01 -n "Dev IHD (Int) A"
squeezelite-i386 -s localhost -o plughw:CARD=Intel,DEV=1 -d all info -f 
/var/log/squeezelite-2.log -m 00:04:20:F2:00:02 -n "Dev IHD (Int) D"

2. Check which MAC address they are using in sendHELLO:

grep mac /var/log/squeezelite-1.log | tail -1 | cut --delimiter=" " --field=4 
38:60:77:8b:16:9a

grep mac /var/log/squeezelite-2.log | tail -1 | cut --delimiter=" " --field=4 
38:60:77:8b:16:9a

What is the expected output? What do you see instead?

It is expected that MAC addresses specified with -m will be used

What version of the product are you using? On what operating system?
v1.6.5, FC20

Please provide any additional information below.

Binary source:
Linux intel 32 bit - 
http://squeezelite-downloads.googlecode.com/git/squeezelite-i386

Original issue reported on code.google.com by and...@falout.org on 2 Jan 2015 at 12:44

[GoogleCodeExporter]

Please use mac addresses which are not from the Slim Devices hardware range 
00:04:20 - the latest versions prevent this and show an error message when you 
try to set that.

Original comment by trio...@btinternet.com on 2 Jan 2015 at 11:04

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for this clarification.

I assume this is the "trap setting of hw player mac address" line in 
ChangeLog.txt? 

May I suggest an edit that would make this change in behaviour a bit more 
obvious to users:

"Prevent user from specifying MAC address on command line that is using 
00:04:20* range, which is used by Logitech hardware players. Issue warning 
message, and force MAC to hard-coded value (38:60:77:8b:16:9a)"

I have SL running as systemd service, so I never had seen the message in log 
file. Which I suppose will be the case with a lot of people. Maybe it would be 
better to abort execution in such cases, when an option specified is no longer 
valid/accepted?

Incidentally, "38:60:77" MAC space belongs to PEGATRON CORPORATION, which is a 
quite large and active manufacturer of various devices, with over 200.000 
employees; if the intention was to avoid potential conflict with an Logitech 
hardware device, this may not be the best choice:

http://en.wikipedia.org/wiki/Pegatron

Thanks,
Andrej

Original comment by and...@falout.org on 3 Jan 2015 at 1:26

[GoogleCodeExporter]

It is not using a hard coded value it falls back to detecting the mac from your 
hardware if possible.

Original comment by trio...@btinternet.com on 3 Jan 2015 at 11:51

[GoogleCodeExporter]

Thanks for that info, very useful.

I suppose I did not expect my Intel made motherboard with intel chipset to 
return 38:60:77 of PEGATRON CORPORATION, but now I see this is indeed the case.

All clear now, please close.

I would still encourage this info to be added to readme or man so folks dont 
add more bug reports because they did not know about it :)

Also, I'm not sure what the logic used to be when multiple instances of SL 
where started without specifying MAC, but possibly refusing to start in that 
scenario might spare a lot of head scratching and wondering why are things not 
working ...

Original comment by and...@falout.org on 4 Jan 2015 at 4:47