A solution for making Client Profile changes stay applied
Posted: Tue Sep 04, 2012 7:25 pm
Have you ever had the need to change the client profile for a device
and noticed that when the server is restarted that those changes are no longer there
Well so did I
To further complicate the issue, this was not always true, sometimes they did stick
I discovered something about client profiles that I had never thought about before
that does effect why some survive changes and some do not
It all has to do with the mapping policy
Here is the definition of the mapping policy taken from the clients.db
Currently in 7.x the MappingUpdatePolicy entry is used for the mapping policy
Prior to 7.x the DB entry was used for the mapping policy
In a nutshell, if a client profile has a mapping policy of AUTO
and you assign it to a client that is not made for that profile
on a server reboot, that client will not get that profile
It needs to be FIX or FIXPC for it to be sticky
and get written to the clients.db or clients.data7
Dont change the following client profiles, bad things will happen
All of these have MappingUpdatePolicy set to AUTO
And are the ones that will not survive a server reboot
if they were not auto assigned by the server to the client
Note:
Why the above are set to AUTO, is anyones guess
As every other client profile is set to either FIX or FIXPC, why not these?
I would add, that those who are creating custom profiles
this info might help you better create a profile that stays applied to a client
and noticed that when the server is restarted that those changes are no longer there
Well so did I
To further complicate the issue, this was not always true, sometimes they did stick
I discovered something about client profiles that I had never thought about before
that does effect why some survive changes and some do not
It all has to do with the mapping policy
Here is the definition of the mapping policy taken from the clients.db
Code: Select all
AUTO, FIX, FIXPC
set to auto if a different client identify string can overrule this entry
set to FIX if the entry can only be overruled by manual user interaction
set to FIXPC for PC software clients,
Code: Select all
<MappingUpdatePolicy>AUTO</MappingUpdatePolicy>
<MappingUpdatePolicy>FIX</MappingUpdatePolicy>
<MappingUpdatePolicy>FIXPC</MappingUpdatePolicy>
Code: Select all
DB:AUTO
DB:FIX
DB:FIXPC
In a nutshell, if a client profile has a mapping policy of AUTO
and you assign it to a client that is not made for that profile
on a server reboot, that client will not get that profile
It needs to be FIX or FIXPC for it to be sticky
and get written to the clients.db or clients.data7
Dont change the following client profiles, bad things will happen
Code: Select all
devicedb\default.xml
devicedb\Generic_DLNA_1.0.xml
devicedb\Generic_Media_Receiver.xml
devicedb\Generic_Music_Only_Receiver.xml
devicedb\PacketVideo\PV_Player.xml
devicedb\PacketVideo\Twonky_Aggregation_Server.xml
devicedb\PacketVideo\Twonky_NMC.xml
devicedb\PacketVideo\TwonkyManager.xml
devicedb\PacketVideo\TwonkyMobile.xml
devicedb\PacketVideo\TwonkyPlayer.xml
devicedb\PacketVideo\TwonkyRenderer.xml
And are the ones that will not survive a server reboot
if they were not auto assigned by the server to the client
Code: Select all
devicedb\Android.xml
devicedb\Apple_iPhone.xml
devicedb\IOMegaNAS.xml
devicedb\Linn\Linn_DS_Music_Player.xml
devicedb\Nokia\Nokia_N95_Phone.xml
devicedb\Nokia\Nokia_Phone.xml
devicedb\Sony\Sony_Blu-Ray_Home_Theater.xml
devicedb\Sony\Sony_Blu-Ray_Player.xml
devicedb\Syabas_Firmware_based.xml
Why the above are set to AUTO, is anyones guess
As every other client profile is set to either FIX or FIXPC, why not these?
I would add, that those who are creating custom profiles
this info might help you better create a profile that stays applied to a client