User Profiles

[DenyAll]

A thought for a potential enhancement for more advanced users: at the moment Serviio loads profiles.xml and application-profiles.xml from the serviio/config folder. These files are overwritten when a new version is released, so any user modifications are lost and have to be re-done.

Would it be possible to load a third file from the same folder, called say user-profiles.xml that contained user profiles. This file would only be loaded if it exists (otherwise skipped - alternatively you could distribute a blank file as long as the installer didn't overwrite it if it existed). In this manner a more advanced user can create and store their own specific device profiles, stored in a file that isn't overwritten by the installer.

Optional - not sure how preference for device detection works if there is a match to two or more profiles, but it would be nice if preference was given to the user-profiles.xml for purposes of device detection (by the <Detection> section). This would enable a user to include the device detection in their profile and not have to remove it from the standard profiles. Everything else follows existing inheritance rules.

If this scheme were adopted it should be possible for a user to write their own profile and profile modifications without ever modifying the standard ones.

[Iveky]

Great idea that could be easily added already in 1.4.1 version?

[zip]

It's doable, but not for 1.4.1, which is code complete now.

[DenyAll]

Thanks zip - have created an issue at https://bitbucket.org/xnejp03/serviio/i ... r-profiles.

[npuser]

if an user has an issue with a device profile, with the option proposed here, it would be tough to pin point whether attributes in userdefined-profiles.xml or profiles.xml are the culprit. I would suggest a priority based profile load approach, meaning if userdefined-profiles.xml esixts; load it last; attributes from userdefined-profiles.xml then overwrite matching attributes loaded previously by profile.xml.

or

Other solution would be to decouple individual device profiles from profiles.xml, create an individual profile files for the device in a folder and load everything *.xml from that folder just like plex.

NPuser

[Iveky]

every profile already has it's unique name, you can't have two profiles with same name (in fact with same Profile ID), see this:

original serviio's profile:

  Code:

   <Profile id="sam_ef" name="Samsung TV / player (E/F-series)" extendsProfileId="1">

mine additions I already added in 1.4.1 profiles.xml beside original serviio's profile

  Code:

   <Profile id="SamsungEF" name="SamsungTV ES6800 from 1.3.1" extendsProfileId="1">

   <Profile id="Samsung68" name="SamsungTV ES6800 ver 1.4" extendsProfileId="1">

   <Profile id="Samsung6800" name="SamsungTV ES6800 ver 1.4.1" extendsProfileId="1">


as you can see, ProfileID distinguish them... but all 4 are for same device (Samsung ES TV) and you choose in console which one to use.

So, best solution is to move these additional profiles to separate file. Easier to handle while modfiing them.

[DenyAll]

This enhancement was really about eliminating the need to re-do all your profile mods every time a new release comes out, but does have some benefit for troubleshooting/profile management.

if an user has an issue with a device profile, with the option proposed here, it would be tough to pin point whether attributes in userdefined-profiles.xml or profiles.xml are the culprit

I saw it the opposite way - that it aids troubleshooting:

• presently, if a user has modified a profile and they need support, they need to specifically state that they have modified the profile. I have had instances when assisting someone who states they are using the xxx profile... only to find some time later that they had modified the xxx profile. This way it will be clear - as Iveky states, they cannot have the same named profile so they will need to provide their modifications with their problem (it also helps as sometimes they forget what they modified - this way its separately identified).
• this will enable users (or people assisting them) to revert back to standard profile easier, so should assist troubleshooting;
• this is targeted at advanced users. I would expect those users to have a full understanding of inheritance - whether its inheriting from a profile in the same file or another I cannot see as a big issue.

The only priority based attribute I am proposing is for detection. This way the user can write a custom profile and have their device auto-detect without also having to remove the detection from the standard profile (it also allows them to revert back to the standard profile easily). Consider a simple mod I currently do every upgrade (it affects only two files in my library) - in the PS3 profile I add the line:

  Code:

   <Matches container="mp4" vCodec="mpeg4"/> <!-- DenyAll -->

(I use the comment to remember my mods). Under this scheme I would create a new profile in the separate file:

  Code:

   <Profile id="myps3" name="My Playstation 3" extendsProfileId="4">
      <Detection>
         <HttpHeaders>
            <X-AV-Client-Info>.*PLAYSTATION 3.*</X-AV-Client-Info>
         </HttpHeaders>   
      </Detection>
      <Transcoding>
         <Video targetContainer="mpegts" targetACodec="ac3" targetVCodec="mpeg2video" aBitrate="384">
            <Matches container="mp4" vCodec="mpeg4"/>
         </Video>
      </Transcoding>
      <ThumbnailsResolution>HD</ThumbnailsResolution>   
   </Profile>

It is more complex than simply adding one line (remember its for more advanced users) - but its also only something I do once, not every upgrade. Auto detection would pick up this profile (as it has priority) and not the standard ps3 profile (which I do not modify in any way).

Now having done this I realise my idea has a flaw. For this to work as I had hoped, all local transcoding blocks in all standard profiles will need to have forceInheritance="true" set to allow user profiles to inherit them. It's a pity that local transcode blocks didn't inherit by default (with an option to set Inheritance="false" where needed) as this would align them more with what happens with most (all?) other elements, but I suspect that that is a historic thing.

ps. It could still work, but with the "myps3" profile as a full copy of the existing playstation profile with the added line. Not as elegant in this case. The other profile I add (for the ios app 8player), would be no issue as it inherits from profile 1, which already has forceInheritance set for its one transcode block.

[jhb50]

This is all now way to complex for me to figure out. Looks like the idea of a simple maintainable, modifiable, user friendly profile per device has evolved into an albatross where users have to wade thru multiple profiles trying to interpret what is inherited and what is overridden with each new beta and release, all in the name of author/developer convenience. Shame.

I'll be overwriting the profiles.xml on future beta/releases with a copy of my former simple maintainable, modified, user friendly C/D profile, and forgo future attempts to support any user questions relating to the transcoding rules in the released profiles.xml

[Iveky]

yes, as jhb50 says, I will continue to use 'my way' of copying full profile from version to version as I am doing right now, and will welcome and accept separation in new file as DannyAll proposed.
no more discussion needed, don't? everyone has its choice how to maintain profiles he needs.