Skip to content

skip lines starting with # for m3u8 files#767

Merged
Et0h merged 1 commit into
Syncplay:masterfrom
Namyts:improve-m3u8-load
May 9, 2026
Merged

skip lines starting with # for m3u8 files#767
Et0h merged 1 commit into
Syncplay:masterfrom
Namyts:improve-m3u8-load

Conversation

@Namyts
Copy link
Copy Markdown
Contributor

@Namyts Namyts commented Mar 14, 2026

Syncplay allows loading from .m3u8 files but doesn't ignore lines starting with # (it treats those lines like files too)

This PR skips lines starting with # when loading an .m3u8 file

@Namyts
Copy link
Copy Markdown
Contributor Author

Namyts commented Apr 30, 2026

Hi @Et0h, any thoughts on this?
It's common for some media players to add data into the m3u8 file using these comments

Bonus thoughts:

  • It would also be a good idea to save & load the current file's timestamp in the m3u8 using the comment feature (this is what some other media players do. VLC uses #EXTVLCOPT:start-time=123)
  • I personally would like a feature which removes viewed files from the playlist
  • I would also like it to autosave the playlist state
  • I would like it to load the last playlist when the client opens if I am first in a room without one

However, these are more opinionated and completely biased towards my use cases, and I actually have my own workarounds for 3 of these with a VLC plugin... so for me the main QoL issue is that syncplay doesnt ignore # lines

@Et0h
Copy link
Copy Markdown
Contributor

Et0h commented Apr 30, 2026

The change in the PR itself seems fine. It is not too complicated and will allow more files to be read.

In terms of your bonus thoughts:

It would also be a good idea to save & load the current file's timestamp in the m3u8 using the comment feature (this is what some other media players do. VLC uses #EXTVLCOPT:start-time=123)

Syncplay allows people to load .m3u8 files but not save them, and if it starts stripping off the # part of the .m3u8 file it might be better if it doesn't save as .m3u8 files.

In terms of saving the playback position, this might work better as part of a feature where the playlist state is automatically saved (as per your later suggestion) rather than as part of saving a playlist .txt file, but I'm not strongly opposed.

While it isn't a feature I'd use myself, if implemented I expect it would need to be optional as some people might not want to save the playback position. I don't mind helping assist someone in developing it, but as I don't plan to use the feature I'm probably not best placed to take the lead on it.

I personally would like a feature which removes viewed files from the playlist

That'd be neat. I am currently working on a Mark as played feature, and I suspect that once that's integrated into Syncplay the code it uses to be able to automatically mark a file as played could be extended to allow for the playlist to be updated. Some thoughts:

  1. There might need to be a slight delay of a few seconds as people might still be playing the end of the previous file.
  2. There might be issues with everyone trying to update the playlist at exactly the same time with duplicate change messages.

As this is a feature I might use I don't mind having a stab at developing it when I have the time, but not sure when that'd be.

I would also like it to autosave the playlist state

So long as this is optional I have nothing against this in principle - it'd presumably have to be tied to the specific server and the specific room. Again, this is not a feature I'd use so I'd probably not be best placed to develop it. I wouldn't want it to write every second to reflect changes in position, so it might want to have some sort of time limit to only do it every X seconds or when there is a list change or when you are about to close or something.

I would like it to load the last playlist when the client opens if I am first in a room without one

Sounds like that'd tie in nicely with the other feature.

@Namyts
Copy link
Copy Markdown
Contributor Author

Namyts commented May 1, 2026

Thanks for your quick & comprehensive reply!
My flow with syncplay at the moment is:

  1. load bookmark.m3u8 (created last session) into syncplay
    b) delete the comment line containing the timestamp from playlist in syncplay
  2. activate my VLC extension - it generates a playlist every time you pause containing the remaining items in an alphabetised folder & the current VLC timestamp (playlist can be read by other media players, but unfortunately there is no universal timestamp comment...)
  3. watch with friends! 🎉 (thanks to syncplay! it's especially great for watching anime where one person likes sub, another dub, and a third uses ai-generated dubtitles...)
  4. when done, I pause VLC -> this generates the new bookmark.m3u8 which is loaded next time!

This PR should solve 1b.

I am currently working on a Mark as played feature

I took a look at something similar prior to my more minimalist fix. The challenge is trying to make something somewhat portable with the feature sets we want. m3u8 really leaves a lot to be desired... (or: I wish there were more standard directives across media players!)
An idea I had was:

  • Construct a m3u8 containing the playlist items (in order)
  • For played items, prepend them as a comment with a directive so that syncplay still loads them, but marks them as played
#EXTVLCOPT:start-time=123
#EXT-SP-WATCHED=item_1
#EXT-SP-WATCHED=item_2
item_3
item_4

This would allow the playlist file to still resume from the correct file (item_3 at 123s (VLC)) in other media players, but keep the extra information for syncplay? (The con is that other media players would only load the remaining partial playlist - which is probably fine from a practical POV, but still a bit lossy)

Anyway... Playlist file standardisation is not something that I can solve, but at the very least... I would appreciate it if at least syncplay would not load the comment lines as files 😉

@Et0h Et0h merged commit ddacb2c into Syncplay:master May 9, 2026
@Et0h
Copy link
Copy Markdown
Contributor

Et0h commented May 9, 2026

Thanks for this fix @Namyts - I've accepted your PR.

Happy to revisit playlist auto-saving/loading as a separate discussion or as a PR - just refer back to this issue.

Auto-delete after an episode is watches is something which could be revisited after #746 has been merged as it should be able to re-use some of the same logic - again, just refer back to this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants