Option to add info columns to the playlist (length, path)

[enchained]

We're using syncplay a lot, and are really grateful for the opportunities it provides. In that time some quality-of-life improvement ideas came to mind and I decided to share them.

At times I noticed that it could be really useful to know the length of each item in the playlist, and maybe even total length at the bottom, cause it makes it easier to decide when to watch what.

Also when we use shared playlist, and one of us adds a generic named file like Deleted Scenes.mkv, it loads the wrong file if there are others like it in the media folder. I guess it could be fixed with advanced matching that uses length and size, hash sum etc, but it can be a bit complex to implement, or maybe was implemented already and I encountered a bug. Either way, simply adding an optional column with a relative path could help dealing with it, and also keeping playlists more visually organized/grouped. By the relative path I mean if media directory is c:/videos/movies, it could be shown in the path column like /movies/movie-name/featurettes/Deleted Scenes.mkv or just /movies/movie-name/featurettes/. An option to have that could be nice.

[Et0h]

I can see why those features would be convenient for certain use cases and it looks simple on the face of it, but actually both of those suggestions would be really difficult to implement and there could be drawbacks/trade-offs to implementing them (not least the general principle that adding complexity can reduce reliability). As such, I don't expect these suggestions to be implemented in Syncplay.

In terms of duration (length), at present Syncplay is agnostic to what is being played and lets the media player obtain the duration and simply uses that. In some cases there are actually more than one way to calculate a duration and it may require the whole file to be loaded into memory. There is no easy cross-platform and cross-player way of getting the duration of a file which is not being played like there is getting the filesize. There could be performance issues, and confusion if the duration obtained through one method is different from the duration obtained from the media player. Your media player might automatically calculate the durations of all files in a playlist, so you might be able to compare files by manually adding them to a media player playlist.

In terms of the filenames, Syncplay is designed to be agnostic as to where a file is located so long as it is in a media directory. Indeed, it is designed so that one person could play a 1080p file and another a 720p file and it would work fine so long as they both had the same filename, so comparing hashes or filesizes is out of the question. Indeed, even if it were simple and reliable to obtain duration (which it is not, as per above) then this could still result in inconsistent behaviour if two files had the same length (which is not unusual) and Syncplay strives to be consistent in how it treats files. The current approach makes it easy to add a file to a playlist because Syncplay knows it only needs to list the filename and not to reveal anything to other users about internal file storage decisions. Syncplay only uses the filename or URL to determine if you are using the right file, and determines which file to play without recourse to other information. As such, users are advised to ensure that each file they want to play has a common and unique filename. If we were to go to all the effort of changing the system then it would raise issues with backwards compatibility, and it would either be a feature which was hidden as you would have to manually edit the playlist to use it or it would add complexity to the UI to add it as an option.

[enchained]

@Et0h Thank you so much for the detailed reply. I didn't realize the complexity of accessing that data without loading, so it all makes sense from that point.

Then I remembered that PotPlayer had a special option to auto-load playlist durations and it always took visible time to load. Thinking about it, without that option PotPlayer was actually caching duration of files that have been opened, and displayed it only for them in the playlist.
Is it something you could maybe consider? Caching duration and path when opening a file, and filling the data next to that file in the playlist. That way the file mixup will be more obvious (to figure out on which side the wrong file was loaded), and just by clicking through the playlist, the duration data could gradually become available too. Caching doesn't sound as much system-changing to break anything. And if the optionality of this UI would add more complexity, the extra info could be done in the tooltip on hover of the cached files instead.

[Et0h]

At the moment I'm generally wanting to avoid adding to the complexity of Syncplay too much, and the more features we have the more things people will have to learn how to use and the more code we will have to maintain for the foreseeable future on multiple platforms across multiple media players.

Syncplay is open source, so anyone who wants to code a feature is able to do so. Whether it would get integrated into the main branch would probably depend on issues such as performance, added complexity, maintainability, and whether it required additional libraries to be loaded.

[Et0h]

I have now added this suggestion to http://syncplay.pl/ideas/ under the heading "Probably adds too much complexity to be worth it" for the reason previously given.