(2015-03-15, 19:25)Montellese Wrote: A while ago I started working on something similar, see https://github.com/Montellese/xbmc/commits/media_window_cleanup (some commets are not related). But I took a different approach where the metadata of an item (movie, episode, ...) could be linked to multiple files. That way you wouldn't have to deal with different metadata for the same item. The implementation in the GUI seems to be similar because when you click on such an item it will open like a movie set and show you all available items.

But I never finished it because there are so many special and edge cases that need attention like which version do you play when a user chooses "Play from here" and other such stuff.

(2015-03-15, 19:56)jjd-uk Wrote: Could you have a Duplicate node for managing similar to the Sets node, this would allow you to remove Duplicates from the Library, and also set which of the duplicates is the Default for actions such as "Play from here" where offering a dialogue to choose is not practical. If there is no user set Default simply use the first item that was added to the Library.

This would negate the need for any attempt at clever logic which will never satisfy everyone.

(2015-03-15, 19:25)Montellese Wrote: A while ago I started working on something similar, see https://github.com/Montellese/xbmc/commits/media_window_cleanup (some commets are not related). But I took a different approach where the metadata of an item (movie, episode, ...) could be linked to multiple files. That way you wouldn't have to deal with different metadata for the same item. The implementation in the GUI seems to be similar because when you click on such an item it will open like a movie set and show you all available items.

But I never finished it because there are so many special and edge cases that need attention like which version do you play when a user chooses "Play from here" and other such stuff.

1. User clicks (Movies->titles) most logic handled in CGUIMediaWindow::Update()
   
2. Background thread grabs items from database (VideoDatabase.cpp::GetMoviesByWhere()) along with media info -- main thread waits for completion updating spinner etc.
   
3. Filters and grouping sorting etc. applied
   - Here we group identical items GroupUtils::Group()
   
4. Load thumbs and stream info GetGroupedItems::Load() calls CBackgroundInfoLoader::Run() on a background thread
   - We have hooks/callback at start and the end of update
   
5. All items are looped through on said background thread, calling CVideoThumbLoader::LoadItemCached() which will get the stream details via CVideoDatabase::GetStreamDetails
   
6. For those items not found in cache CVideoThumbLoader::LoadItemLookup() loads stream info from the file directly and caches it for next time
   - For each item when 5-6 are complete we have a hook OnItemLoaded() callback this doesn't seem to be used for GUI update, not 100% when the update gets pushed to the the GUI.
   
7. We are done the skin now shows media info such as HD etc.
   

1. I think jjd-uk's idea of creating a duplicate node as a subclass CFileItem would be useful (This might already exist), then we could maintain a list of subnodes and hence update cached info for all children and select the best in the background step getting stream details. We could also re-implement "play from here" in a sane manner and other edge cases as they arise. Looking at Montellese's branch I think this might be as simple as moving this logic from Group to BackgroundInfoLoader.
   
2. Delay grouping until after media stream are loaded on the callback. This seems like a bad way to go as it would likely confuse the user, as items suddenly disappear as they are merged.
   
3. Get cached stream details when we initially load the items from the database (i.e. do step 5. in step 1.), however this would still require special handing for the slower non-cached case.
   

(2015-03-21, 05:48)rsanger Wrote: The use of the database to keep lists of related files seems like a good idea and could reduce load times of a database with many duplicates particularly on load end devices.

(2015-03-21, 05:48)rsanger Wrote: I don't like the idea of merging video/sound and subtitles together independently GroupUtils.cpp, different files are likely to be slightly different lengths and would cause out of sync sound etc.

(2015-03-21, 05:48)rsanger Wrote: NOTE: This actually doesn't work because the stream information is not yet being loaded (see Issue 1 below).

(2015-03-21, 05:48)rsanger Wrote: Issue 1

One of the biggest problems at the moment is that the stream data is not loaded until after the grouping, which is the simplest place to find the best stream to report for HD/SD. This also means that
"play" in the context menu could play this best stream and if we could add back "play from here" (disabled because the items are directories) we could play the best streams we've found.

Solution (1 seems to be the best)

1. I think jjd-uk's idea of creating a duplicate node as a subclass CFileItem would be useful (This might already exist), then we could maintain a list of subnodes and hence update cached info for all children and select the best in the background step getting stream details. We could also re-implement "play from here" in a sane manner and other edge cases as they arise. Looking at Montellese's branch I think this might be as simple as moving this logic from Group to BackgroundInfoLoader.
   
2. Delay grouping until after media stream are loaded on the callback. This seems like a bad way to go as it would likely confuse the user, as items suddenly disappear as they are merged.
   
3. Get cached stream details when we initially load the items from the database (i.e. do step 5. in step 1.), however this would still require special handing for the slower non-cached case.
   

(2015-03-21, 05:48)rsanger Wrote: Should we 1) provide this as a directory if clicked upon as currently implemented, or 2) just default to the best stream and put alternative streams hidden in the context menu?
I like the idea of 2. But we could provide a setting to switch between these modes?

(2015-03-21, 05:48)rsanger Wrote: How should we differentiate files, could we show the shortest difference in the path here? And/Or let the users decide some form of regex matching?
- E.g. {/media/driveA/movies/mov.mkv , /media/driveB/mov.mkv} would become {driveA , driveB}
- E.g. {/media/driveA/movies/mov.mkv , /media/driveB/mov.mkv , /media/driveB/movies/mov.mkv} would become {driveA , driveB , driveB/movies }

(2015-03-25, 14:31)Montellese Wrote:

(2015-03-21, 05:48)rsanger Wrote: The use of the database to keep lists of related files seems like a good idea and could reduce load times of a database with many duplicates particularly on load end devices.

Yes it makes grouping easier and more unified (e.g. also for other APIs like JSON-RPC). It however has the disadvantage that you e.g. can't store different artwork per version.

(2015-03-25, 14:31)Montellese Wrote:

(2015-03-21, 05:48)rsanger Wrote: I don't like the idea of merging video/sound and subtitles together independently GroupUtils.cpp, different files are likely to be slightly different lengths and would cause out of sync sound etc.

I don't follow. When you would play such an item you wouldn't play the grouped item but one of the specific versions so the streamdetails in the grouped item wouldn't have any influence on playback but only on how it is displayed in the GUI listing.

(2015-03-25, 14:31)Montellese Wrote:

(2015-03-21, 05:48)rsanger Wrote: Issue 1

One of the biggest problems at the moment is that the stream data is not loaded until after the grouping, which is the simplest place to find the best stream to report for HD/SD. This also means that
"play" in the context menu could play this best stream and if we could add back "play from here" (disabled because the items are directories) we could play the best streams we've found.

Solution (1 seems to be the best)

1. I think jjd-uk's idea of creating a duplicate node as a subclass CFileItem would be useful (This might already exist), then we could maintain a list of subnodes and hence update cached info for all children and select the best in the background step getting stream details. We could also re-implement "play from here" in a sane manner and other edge cases as they arise. Looking at Montellese's branch I think this might be as simple as moving this logic from Group to BackgroundInfoLoader.
   
2. Delay grouping until after media stream are loaded on the callback. This seems like a bad way to go as it would likely confuse the user, as items suddenly disappear as they are merged.
   
3. Get cached stream details when we initially load the items from the database (i.e. do step 5. in step 1.), however this would still require special handing for the slower non-cached case.
   

IMO option 1 is the only way that really makes sense both from a development and a user point of view. Furthermore determining the actual item to be played is something that only really needs to happen after the user has chosen to play the item.

(2015-03-25, 14:31)Montellese Wrote:

(2015-03-21, 05:48)rsanger Wrote: Should we 1) provide this as a directory if clicked upon as currently implemented, or 2) just default to the best stream and put alternative streams hidden in the context menu?
I like the idea of 2. But we could provide a setting to switch between these modes?

IMO the problem with simply playing one version is that it will be very hard to find a generic way to determine the version to be played. Some people prefer the version with highest resolution, others the version with best audio, others the version in a specific language and so on and so forth. Therefore I think that there's no generic way to do this and we'll have to provide users with the possibility to choose between different approaches and to allow them to override that approach for specific items by manually defining the best version.

(2015-03-25, 14:31)Montellese Wrote:

(2015-03-21, 05:48)rsanger Wrote: How should we differentiate files, could we show the shortest difference in the path here? And/Or let the users decide some form of regex matching?
- E.g. {/media/driveA/movies/mov.mkv , /media/driveB/mov.mkv} would become {driveA , driveB}
- E.g. {/media/driveA/movies/mov.mkv , /media/driveB/mov.mkv , /media/driveB/movies/mov.mkv} would become {driveA , driveB , driveB/movies }

For a start I was just using the same title with the possibility for users to specify a specific name (e.g. "Director's Cut") per version.

(2015-03-31, 13:29)rsanger Wrote: I've been using the CFileItemList to hold all merged CFileItem. One annoyance is that it is assumed that all items will be CFileItems and are often copied as such losing any subclass information, so there are some hacks to work around this.

(2015-03-31, 13:46)Montellese Wrote: What is the advantage of holding the merged CFileItem instances in a CFileItemList instance? IMO this sounds like a major change in the CFileItemList class which is used all over the place and every one of these places probably assumes that every item is a CFileItem and not a CFileItemList and has quite some potential for weird bugs.

(2015-03-31, 14:08)rsanger Wrote:

(2015-03-31, 13:46)Montellese Wrote: What is the advantage of holding the merged CFileItem instances in a CFileItemList instance? IMO this sounds like a major change in the CFileItemList class which is used all over the place and every one of these places probably assumes that every item is a CFileItem and not a CFileItemList and has quite some potential for weird bugs.

The main reason for this is to store the items that made up the group such that the background thread loading streaminfo and thumbnail loading can access each and get the streaminfo. Keeping the entire item makes it simple to call LoadInfo...() on each and then pick the best etc. It also means we have the path if we want to default to playing the best item.

Another option for dealing with this would be to keep a list of the file paths against a CFileItem and recreate these items as needed from this.

(2015-04-02, 17:58)Montellese Wrote:

(2015-03-31, 14:08)rsanger Wrote:

(2015-03-31, 13:46)Montellese Wrote: What is the advantage of holding the merged CFileItem instances in a CFileItemList instance? IMO this sounds like a major change in the CFileItemList class which is used all over the place and every one of these places probably assumes that every item is a CFileItem and not a CFileItemList and has quite some potential for weird bugs.

The main reason for this is to store the items that made up the group such that the background thread loading streaminfo and thumbnail loading can access each and get the streaminfo. Keeping the entire item makes it simple to call LoadInfo...() on each and then pick the best etc. It also means we have the path if we want to default to playing the best item.

Another option for dealing with this would be to keep a list of the file paths against a CFileItem and recreate these items as needed from this.

IMO you only need the information about all the available versions when the user wants to play/queue directly from the grouped list. In all other cases that information is useless and for that the change seems rather risky. It should be enough to retrieve all the necessary streamdetails and file paths once the user initiates that action instead of having to keep it around all the time.

(2015-03-31, 13:29)rsanger Wrote:

(2015-04-02, 17:58)Montellese Wrote:

(2015-03-31, 13:29)rsanger Wrote: How should we differentiate files, could we show the shortest difference in the path here? And/Or let the users decide some form of regex matching?
- E.g. {/media/driveA/movies/mov.mkv , /media/driveB/mov.mkv} would become {driveA , driveB}
- E.g. {/media/driveA/movies/mov.mkv , /media/driveB/mov.mkv , /media/driveB/movies/mov.mkv} would become {driveA , driveB , driveB/movies }

For a start I was just using the same title with the possibility for users to specify a specific name (e.g. "Director's Cut") per version.

The sounds like a good idea. I guess this would require some extra storage in the database, so this is probably one of the last aspects I'll focus on.

(2015-04-07, 09:36)rsanger Wrote: I will try to remove CFileItemList, I'll probably end up putting some extra fields into CFileItem to hold the paths(but not the full CFileItems). I don't know the code very well and wouldn't want to break things with this change.

(2015-04-07, 09:36)rsanger Wrote: I've noticed that the existing Context Menu->Manage->Edit Title already does this.