MAX_FILENAME_LENGTH causing different filename error.

[Spoorloos]

Describe the bug

MAX_FILENAME_LENGTH constant (set to 250) causes it to cut off the filename at the end of media URLs over 250 characters long, which causes the different filename error.

To Reproduce

Put a long media URL (over 250 characters). Personally I get mine from AIOStreams/Stremio

Expected behavior

That it doesn't do that

[Et0h]

Hi @Spoorloos I've made #801 to try to fix this issue.

Because longer filenames can cause overly long messages I had to develop a system to get around that issue and allow up to 2,000 characters per filename/path.

If the file/path is more than 2,000 it should still work, it'll just be hashed in what the client sends to the server.

Are you in a position to test the new system on a private server and try the new client (potentially also with some on the old client) and report back?

[Spoorloos]

Hi @Spoorloos I've made #801 to try to fix this issue.

Because longer filenames can cause overly long messages I had to develop a system to get around that issue and allow up to 2,000 characters per filename/path.

If the file/path is more than 2,000 it should still work, it'll just be hashed in what the client sends to the server.

Are you in a position to test the new system on a private server and try the new client (potentially also with some on the old client) and report back?

Hi,

I'm currently self hosting so let me know what I can do for you. I'd love to help out.

[Et0h]

@Spoorloos That's great, thanks. The most useful thing would be to try the new client and server from this build:

https://github.com/Syncplay/syncplay/actions/runs/33176162645?pr=801

This is a slightly updated version of the PR.

What to test

If possible, please try:

• new client with new server
• new client with old server
• old client with new server

For each combination, try a normal filename or URL, one around 1,000 characters long, and one around 3,000 characters long.

An easy way to make a very long test URL is to add a long query string after a question mark, for example:

https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/360/Big_Buck_Bunny_360_10s_30MB.mp4?<lots of characters>

You may need to add test-videos.co.uk as a trusted domain in Syncplay.

What should happen

With the new client and server, filenames and URLs up to 2,000 characters should normally be shared in full.

When a new client is used with an old server, it falls back to the older 250 character limit. Longer filenames or URLs may therefore appear as a 12 character hash instead of the full name. Hashes may also be used in other situations where the server needs to reduce the size of a user list message.

The main thing to watch is what actually appears in the client. If the new client can work out what a hash represents, it should show the recognised filename or URL rather than leaving the 12 character hash visible. Older clients will continue to show those filenames or URLs as hashes.

It should normally be able to recognise the full name if it is in the current shared playlist, or if that same file or URL has previously been opened on that client during the current Syncplay session.

If the client genuinely has no way of knowing what a hash represents, seeing the hash itself is expected.

For a long URL which the client has successfully recognised, please also try right clicking it in the user list and using actions such as Open stream or Add stream to playlist. These should use the original working URL, even if the version shown in the user list has been made more readable.

Very long filenames or URLs should not cause users to disconnect, and playback and synchronisation should continue to work normally.

Testing several users at once

It would also be useful to test several users at once with long filenames or URLs.

The server sends the complete user list as a single message, and that message must be smaller than 16,384 bytes. This means that several individually valid long filenames can still make the combined user list too large. The new server is supposed to use hashes behind the scenes where necessary to keep the message within that limit, with new clients then resolving those hashes back to the normal filename or URL where possible. Older clients will continue to show the hashes.

A simple way to test this is:

1. Connect several clients to the same room.
2. Give each client a long filename or URL, preferably around 1,500 to 2,000 characters.
3. Start with a few users, then add more users until some filenames stop appearing in full and are shown as 12 character hashes instead on the old clients. With names around 2,000 characters long, this may start happening at roughly 7 to 8 users; with names around 1,500 characters, it may take closer to 9 to 10. The exact point will vary because the 16,384 byte message also contains the rest of the user information.
4. Check that the clients stay connected and continue working normally.
5. On the old clients, check that only some filenames are replaced by hashes at first, rather than every filename being replaced unnecessarily.
6. Then make the user list smaller again, for example by disconnecting some users or switching them to shorter filenames.
7. Check that the full filenames appear again on the old clients once the message is small enough.

On a new client, a filename which the server has represented as a hash may still appear in full if the client can recognise it from the shared playlist or from a file or URL it has already opened during the current Syncplay session.

The main Syncplay window of new clients should be able to show the full recognised filename information. URLs shown in the user list may be made more readable for display, but actions on them should still use the original URL. The media player OSD should shorten very long names to 250 characters (or less, e.g. MPC-HC which has a shorter limit), remove login information from the start of paths, and to decode %XX URL encodings to make it easier to read.

If something goes wrong

Please let me know:

• which client/server combination you were using
• roughly how long the filename or URL was
• how many users were connected
• what appeared in the user list, especially if a 12 character hash remained visible on a new client when you expected it to know the filename
• whether right click actions on a recognised long URL opened or added the correct URL
• whether playback or the connection was affected

A screenshot would also be useful if something looks wrong.