Update external-player-map.json: Add basic support for external SMPlayer

[trostboot]

Add basic functionality to open videos in SMPlayer

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

closes #2231

Description

Adds basic functionality to open videos in SMPlayer.

Adding more parameters (e.g., startOffset or speed) is not possible at this time as SMPlayer expects different formatting compared to what FreeTube currently passes through.

Screenshots

Testing

Testing has been done on Windows 11 x64 only.

Desktop

• OS: Windows
• OS Version: 11
• FreeTube version: v0.18.0-nightly-3109

Additional context

[ChunkyProgrammer]

How do you normally set the start offset from the cli with SMPlayer for YouTube videos?

[trostboot]

By passing the -start switch with the desired offset, e.g.
smplayer -start 15 %url%
Accepts either seconds or hh:mm:ss timecodes.
Alternatively it also parses standard Youtube timecodes in the URL.

Setting startOffset to "-start " does not work as it's parsed as a separate input URL.

[10:17:47:583] SMPlayer::processArgs: arguments: 3
[10:17:47:583] SMPlayer::processArgs: 0 = C:\Program Files\SMPlayer\SMplayer.exe
[10:17:47:583] SMPlayer::processArgs: 1 = -start 25
[10:17:47:583] SMPlayer::processArgs: 2 = https://www.youtube.com/ [...]
[10:17:47:583] SMPlayer::processArgs: files_to_play: count: 2
[10:17:47:583] SMPlayer::processArgs: files_to_play[0]: '-start 25'
[10:17:47:583] SMPlayer::processArgs: files_to_play[1]: 'https://www.youtube.com/ [...]'

vs invoking it from a terminal:

[10:32:54:948] SMPlayer::processArgs: arguments: 4
[10:32:54:948] SMPlayer::processArgs: 0 = C:\Program Files\SMPlayer\smplayer.exe
[10:32:54:948] SMPlayer::processArgs: 1 = -start
[10:32:54:948] SMPlayer::processArgs: 2 = 25
[10:32:54:948] SMPlayer::processArgs: 3 = https://www.youtube.com/ [...]
[10:32:54:948] SMPlayer::processArgs: initial_second: 25
[10:32:54:948] SMPlayer::processArgs: files_to_play: count: 1
[10:32:54:948] SMPlayer::processArgs: files_to_play[0]: ' https://www.youtube.com/ [...]'

Other options differ more substantially as they would have to be passed via the -actions switch, e.g.
smplayer -actions "set speed 2" %url%
for 2x playback speed. However, in my testing, passing options via -actions was not very reliable. Would have to further investigate potential causes.

[ChunkyProgrammer]

This patch seems to be getting the start offset to work for me

diff --git a/src/renderer/store/modules/utils.js b/src/renderer/store/modules/utils.js
index 1f4edda9..454c5936 100644
--- a/src/renderer/store/modules/utils.js
+++ b/src/renderer/store/modules/utils.js
@@ -523,7 +523,12 @@ const actions = {

     if (payload.watchProgress > 0 && payload.watchProgress < payload.videoLength - 10) {
       if (typeof cmdArgs.startOffset === 'string') {
-        args.push(`${cmdArgs.startOffset}${payload.watchProgress}`)
+        if (cmdArgs.startOffset.endsWith('=')) {
+          args.push(`${cmdArgs.startOffset}${payload.watchProgress}`)
+        } else {
+          // special handling for SMPlayer and similar
+          args.push(cmdArgs.startOffset, payload.watchProgress)
+        }
       } else if (!ignoreWarnings) {
         showExternalPlayerUnsupportedActionToast(externalPlayer, 'starting video at offset')
       }

diff --git a/static/external-player-map.json b/static/external-player-map.json
index f77ae13c..0885eb40 100644
--- a/static/external-player-map.json
+++ b/static/external-player-map.json
@@ -69,7 +69,7 @@
             "supportsYtdlProtocol": true,
             "videoUrl": "",
             "playlistUrl": "",
-            "startOffset": null,
+            "startOffset": "-start",
             "playbackRate": null,
             "playlistIndex": null,
             "playlistReverse": null,

[trostboot]

I can confirm that works. I've added it to this PR, hope you don't mind.

[ChunkyProgrammer]

I don't mind at all 😊

[PikachuEXE]

Math.trunc might only be applicable for SMPlayer
But I have no better alternative yet

[trostboot]

@PikachuEXE Well, the question that needs to be asked is if there is any value in passing along fractions of a second to begin with.
For one, links within Youtube itself only have a precision of whole seconds.
For another, Freetube itself is currently inconsistent in how it handles this (which is why I initially didn't catch the issue with SMPlayer).

If you open a link to an external player from within the Freetube video player with some amount of progress in a video, it will only pass on integer seconds, so I would assume there is some truncating already going on somewhere.
If you then go back to e.g. your subscription page and open that same video with some saved progress in an external player, Freetube will pass along non-integer seconds.

If indeed the behaviour of the player page is the desired behaviour, then my fix is just a band-aid and this should probably be handled further up the chain.
Either way, the behaviour should probably be consistent across different sections of the app.

[PikachuEXE]

I have no idea what payload.watchProgress can contain
If it contains non integer numbers and it breaks stuff on external players
I wonder why we don't use it in all conditions... (coz existing external players ignore decimal places?)

But I am fine with a band-aid for one player, we can fix it more properly when more external players added

[efb4f5ff-1298-471a-8973-3d47447115dc]

Thanks @trostboot for contributing!

If u are interested there are more issues open to support external players so u might want to look into that.