#139
- Created on2008-03-27 10:57
- Reported by
- StatusNew
- PriorityNormal (3)
- Assigned to
- Milestone-
- Plan Level-
- Due Date-
Support multiple player with differing capabilities
Store details for all of the media found as users may have different players on their networks which each support formats. This media items being displayed would then be restricted to only those types supported by the player in use.
For example, a network containing both a popcorn-hour player and showcenter player would index all .mkv files owned by the user. However, only when browsing via the popcorn-hour player would these mkv files be displayed in the UI.
For example, a network containing both a popcorn-hour player and showcenter player would index all .mkv files owned by the user. However, only when browsing via the popcorn-hour player would these mkv files be displayed in the UI.
Leave a comment
Implementation thoughts:
Create a table FORMATS with columns FORMAT_ID, MEDIA_TYPE and FILE_EXT (and maybe FORMAT_DESC).
Create a table PLAYER_FORMATS with columns PLAYER_TYPE and FORMAT_ID Each player could have multiple rows within the table (one for each format supported) which would then be joined to the media table when fetching the rows to display.
Note: It would be most efficient if the media tables (mp3s, movies, etc) contained a FORMAT_ID column which was populated at the time the media was discovered, rather than using SUBSTR to get the file extension at query time.
Create a table FORMATS with columns FORMAT_ID, MEDIA_TYPE and FILE_EXT (and maybe FORMAT_DESC).
Create a table PLAYER_FORMATS with columns PLAYER_TYPE and FORMAT_ID Each player could have multiple rows within the table (one for each format supported) which would then be joined to the media table when fetching the rows to display.
Note: It would be most efficient if the media tables (mp3s, movies, etc) contained a FORMAT_ID column which was populated at the time the media was discovered, rather than using SUBSTR to get the file extension at query time.
Implementation thoughts:
Create a table FORMATS with columns FORMAT_ID, MEDIA_TYPE and FILE_EXT (and maybe FORMAT_DESC).
Create a table PLAYER_FORMATS with columns PLAYER_TYPE and FORMAT_ID Each player could have multiple rows within the table (one for each format supported) which would then be joined to the media table when fetching the rows to display.
Note: It would be most efficient if the media tables (mp3s, movies, etc) contained a FORMAT_ID column which was populated at the time the media was discovered, rather than using SUBSTR to get the file extension at query time.
Create a table FORMATS with columns FORMAT_ID, MEDIA_TYPE and FILE_EXT (and maybe FORMAT_DESC).
Create a table PLAYER_FORMATS with columns PLAYER_TYPE and FORMAT_ID Each player could have multiple rows within the table (one for each format supported) which would then be joined to the media table when fetching the rows to display.
Note: It would be most efficient if the media tables (mp3s, movies, etc) contained a FORMAT_ID column which was populated at the time the media was discovered, rather than using SUBSTR to get the file extension at query time.
Implementation thoughts:
Create a table FORMATS with columns FORMAT_ID, MEDIA_TYPE and FILE_EXT (and maybe FORMAT_DESC).
Create a table PLAYER_FORMATS with columns PLAYER_TYPE and FORMAT_ID Each player could have multiple rows within the table (one for each format supported) which would then be joined to the media table when fetching the rows to display.
Note: It would be most efficient if the media tables (mp3s, movies, etc) contained a FORMAT_ID column which was populated at the time the media was discovered, rather than using SUBSTR to get the file extension at query time.
Create a table FORMATS with columns FORMAT_ID, MEDIA_TYPE and FILE_EXT (and maybe FORMAT_DESC).
Create a table PLAYER_FORMATS with columns PLAYER_TYPE and FORMAT_ID Each player could have multiple rows within the table (one for each format supported) which would then be joined to the media table when fetching the rows to display.
Note: It would be most efficient if the media tables (mp3s, movies, etc) contained a FORMAT_ID column which was populated at the time the media was discovered, rather than using SUBSTR to get the file extension at query time.
(In revision:1349) Added a 'Supported Players' section to the config. This allows SwissCenter to determine the players capabilities based upon it's make and model number. The POD parameters used to play audio and images can also be configured for each player. All settings are also written to a config_players.xml. Refs* 139
Other changes relating to player compatibility:
- Invalid player/client details are no longer stored.
- All NMT players are automatically identified with model number > 400.
- Font sizes of NMT players are now aligned with older players. Screens on old and new players will now look very similar.
- Resolution when using PC browser can now be selected in the Miscellaneous section.
- Highlighted menu items now scroll text rather than being truncated (NMT only).
- YouTube and Apple Trailers only available on NMT players.
Other changes relating to player compatibility:
- Invalid player/client details are no longer stored.
- All NMT players are automatically identified with model number > 400.
- Font sizes of NMT players are now aligned with older players. Screens on old and new players will now look very similar.
- Resolution when using PC browser can now be selected in the Miscellaneous section.
- Highlighted menu items now scroll text rather than being truncated (NMT only).
- YouTube and Apple Trailers only available on NMT players.
(In revision:1352) Added a check to ensure that the config_players.xml is imported to the database.
Refs* 139
Refs* 139