Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Piblokto]

My previous posts refer - http://yabb.jriver.com/interact/index.php/topic,106879.0.html.

I have been trying to attain a stable installation of Media Center on Arch Linux but it will not retain the licence. I could not resolve the problem at the time of my previous post and have tried periodically since, hoping that updates may have changed the situation.  It has failed again today on a fresh Antergos installation and my restore count is now down to 0.

The problem is on my office/server PC which houses an SSD for OS plus 3 spinning data drives.  I have tried Arch, Manjaro and am now using Antergos.  I have tried on various partitions including a bare SSD with all other drives disconnected.  Each time the licence is stored and then lost after a few minutes.  My client PC is running Antergos and MC with no problem at all so I can only conclude that it is caused by the hardware/Arch combination of the server PC.

I keep 2 Linux OS's installed in case one becomes unstable, the second is Mint and has no problem with MC, but I would prefer to use Arch as this gives access to other software.  As it is I have to dual boot between the two depending on what work I am doing, which is a drag hence my regular attempts to get a stable MC licence.

Please reset the resore count.

[Awesome Donkey]

Hmmm, I've used all three (and use Arch in my quadruple boot setup) and the license has always maintained, so something must be changing which causes this to happen. Are you changing the hostname or something like this? Are you installing MC from AUR?

[JimH]

Are you changing the name of the system?

I reset your restores.

[mwillems]

I've also seen recurring loss of license on one of my Arch systems, but only one of them which is very odd.  It seems to coincide with updates to MC for me, but I haven't been able to figure out what it is about that specific Arch system that causes the license to fail.  The only difference I can think of is that the machine in question dual boots and has the same host name on both the Windows and the Linux side, whereas most of my other systems are linux only.  But I the windows license never seems to have any problems so I doubt that's it.

[JimH]

Does the IP address change?

[mwillems]

Does the IP address change?

The external or the internal?  Both do change periodically as I don't have a static IP from my ISP, and the device is a laptop so it gets a random IP from my DHCP server.  That is a differentiator: the other machines where the license is stable are wired and have a static internal IP address.  I also travel with the machine that loses its license so it probably shows up with all kinds of different IPs over time as I'm logging into hotel wifi or using my phone as a hotspot, etc.

That's definitely something that separates that machine from the others where things work fine.

[JimH]

Internal.  Thanks.  DHCP shouldn't be a problem.

[Piblokto]

Thanks for the responses.

To answer the queries - as far as I know I am not changing anything and yes, I am installing from the AUR (I'm not yet very confident with the package-building process).  A couple of weeks ago I changed the router setting to switch to a static internal IP address for both the server PC and the client HTPC so that was the setup for the last try.

A couple of months ago I temporarily had a spare SSD available and decided that I would try every option to finally deal with the problem so I installed various Arch-based OS's and desktops (I use KDE).  After these all failed I disconnected all drives, formatted the SSD and installed an OS (probably Manjaro) with it being the only disc in the system and then installed MC with no other software added.  I populated the library with one song so that it replicated a real situation.  It lasted a few minutes but then failed.  The licence is lost with nothing else happening of my volition, not even closing MC - I check the help menu and it shows the option for licence information, I check it again and it has replaced that with the option to install the licence.

I have tried every test I can think of so can only assume that the Arch system/kernel doesn't work correctly with my hardware.  The last Antergos update (last week) installed Plasma 5.9 and a new kernel and it now gives ACPI error messages during boot which I don't get on the client PC which has the same OS on a newer, Gigabyte motherboard.  My searches suggest that this error message indicates a problem with the 4.9 kernel and the bios (Asus Z87-Pro m/b) so maybe the hardware has been causing a conflict with other parts of the OS.

As far as I am now concerned this is an issue with this PC and not MC.  If you can think of any other things I can try then I will happily do so.  I did wonder if there was any logging I could do to identify any running background services that might have caused the licence to be removed but would need support to know how to do that.  I identified the folder that holds the licence information and see that this changes when the licence is installed so something is clearly writing to the file to remove the licence but I don't understand what triggers that action - would a system log enable that?

[JimH]

You might try a Google search to see if some security software is causing similar problems for others.

[mwillems]

I think I cracked the code on why my license was failing on that one machine and none of the others, and this is very likely one for the weird and wonderful issues thread.  Hopefully Jim or someone at JRiver can confirm that my theory is correct or not.

Recently (as of version 1.4) Network Manager (a popular Linux networking tool) enabled a new feature.  To protect user privacy on public wifi, Network Manager now randomizes the MAC address of the wifi interface when scanning for wifi access points by default.  It's a default that can be disabled, and some distros have disabled it, but Arch did not.  As I noted previously most of my Arch machines didn't have any license issues; on examination all but one of my Arch machines don't use Network Manager or were configured before Network Manager version 1.4 (so had the old defaults). 

My machine where the license kept failing had the new defaults and was picking up a random MAC address every time it connected to a different wifi access point, which seems to be what triggers the license failure (or at least I managed to reproduce a license failure that way).  If the JRiver licensing validation relies in part on MAC addresses to identify devices, I think we've found the culprit (at least for my case).

The Network Manager release in question came out in August of last year, but hasn't trickled in to all the Linux distros yet, but has been in Arch since September.  Unless the distros alter the defaults, I would expect this issue to start trickling into other distros soon enough.  Accordingly the top poster notes that he has the issue with Arch based distros, but not with Mint (which is running an older version of network manager). 

If anyone else who is having this problem on Arch can test my solution by adding the following two lines to /etc/NetworkManager/NetworkManager.conf

Code: [Select]

[device]
wifi.scan-rand-mac-address=no
[connection]
wifi.cloned-mac-address=permanent

That will stop the randomization and make network manager use the actual physical MAC of your device (after a reboot).  I expect to have one more license invalidation, but after that I'm hoping it will stay put.  Testing is appreciated.

[bob]

I think I cracked the code on why my license was failing on that one machine and none of the others, and this is very likely one for the weird and wonderful issues thread.  Hopefully Jim or someone at JRiver can confirm that my theory is correct or not.

Recently (as of version 1.4) Network Manager (a popular Linux networking tool) enabled a new feature.  To protect user privacy on public wifi, Network Manager now randomizes the MAC address of the wifi interface when scanning for wifi access points by default.  It's a default that can be disabled, and some distros have disabled it, but Arch did not.  As I noted previously most of my Arch machines didn't have any license issues; on examination all but one of my Arch machines don't use Network Manager or were configured before Network Manager version 1.4 (so had the old defaults). 

My machine where the license kept failing had the new defaults and was picking up a random MAC address every time it connected to a different wifi access point, which seems to be what triggers the license failure (or at least I managed to reproduce a license failure that way).  If the JRiver licensing validation relies in part on MAC addresses to identify devices, I think we've found the culprit (at least for my case).

The Network Manager release in question came out in August of last year, but hasn't trickled in to all the Linux distros yet, but has been in Arch since September.  Unless the distros alter the defaults, I would expect this issue to start trickling into other distros soon enough.  Accordingly the top poster notes that he has the issue with Arch based distros, but not with Mint (which is running an older version of network manager). 

If anyone else who is having this problem on Arch can test my solution by adding the following two lines to /etc/NetworkManager/NetworkManager.conf

Code: [Select]

[device]
wifi.scan-rand-mac-address=no
[connection]
wifi.cloned-mac-address=permanent

That will stop the randomization and make network manager use the actual physical MAC of your device (after a reboot).  I expect to have one more license invalidation, but after that I'm hoping it will stay put.  Testing is appreciated.

You got it. That will definitely mess up the licensing.

[mwillems]

You got it. That will definitely mess up the licensing.

So far it's fixed on my end, thank heaven for small favors!

[Piblokto]

Thank you very much mwillems, this is working for me so far and explains why my second PC holds its licence - it doesn't have a wifi connection, only ethernet.

As far as I am concerned I can mark this solved.  Much respect for the detailed knowledge.

[Awesome Donkey]

Also explains why it didn't happen to me as well since I don't currently use WiFi either.