Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add support for windows wsl2 #1190

Merged
merged 9 commits into from Aug 9, 2023
Merged

Conversation

Vergenter
Copy link
Contributor

@Vergenter Vergenter commented Aug 7, 2023

Pull Request Template

Type of change

  • Bug fix
  • Feature
  • Documentation update

Description

This update provides a simpler method for Windows users to use the application when utilizing WSL2.
A current issue exists with syncplay. It does not work correctly. Simple way to reproduce it is to run it from WSL2 using:

"/mnt/c/Program Files (x86)/Syncplay/syncplay.exe"

It silently fails if a URL is specified(even during runtime), causing the window to close unexpectedly. A workaround for this is: (not currently applied)

cmd.exe /C "C:\Program Files (x86)\Syncplay\syncplay.exe" "$URL"

Moreover, using uname -s to switch cases for syncplay is insufficient and requires modification.

-s | --syncplay)
            case "$(uname -s)" in
                Darwin*) player_function="/Applications/Syncplay.app/Contents/MacOS/syncplay" ;;
                MINGW* | *Msys)
                    export PATH="$PATH":"/c/Program Files (x86)/Syncplay/"
                    player_function="syncplay.exe"
                    ;;
                *) case "$(uname -r)" in
                    *WSL2*)
                        export PATH="$PATH:/mnt/c/Program Files (x86)/Syncplay/"
                        player_function="syncplay.exe"
                        ;;
                    *)
                        player_function="syncplay"
                        ;;
                esac

                ;; 
            esac
            ;;

The checks I've confirmed manually are already marked. Other checks, not yet verified, should function correctly given that only the display program is being modified. I will complete the rest after resolving the syncplay issue.

Checklist

  • any anime playing
  • bumped version

  • next, prev and replay work
  • -c history and continue work
  • -d downloads work
  • -s syncplay works
  • -q quality works
  • -v vlc works
  • -e select episode works
  • -S select index works
  • -r range selection works
  • --dub and regular (sub) mode both work
  • all providers return links (not necessarily on a single anime, use debug mode to confirm)

  • -h help info is up to date
  • Readme is up to date
  • Man page is up to date

Additional Testcases

  • The safe bet: One Piece
  • Episode 0: Saenai Heroine no Sodatekata ♭
  • Unicode: Saenai Heroine no Sodatekata ♭
  • Non-whole episodes: Tensei shitara slime datta ken (ep. 24.5, ep. 24.9)

@port19x
Copy link
Collaborator

port19x commented Aug 7, 2023

I'm skeptical if we should explicitly support this in a documented fashion.
Your changes to the ani-cli matching are welcome tho.

As you see some automated checks failed, clean those up and I'll do a more thorough review

@Vergenter Vergenter changed the title Add support for windows wsl2 feat: Add support for windows wsl2 Aug 7, 2023
@Vergenter Vergenter changed the title feat: Add support for windows wsl2 feat: add support for windows wsl2 Aug 7, 2023
@justchokingaround
Copy link
Collaborator

no need to add that to the README

Copy link
Collaborator

@port19x port19x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, readme is fat enough as is

README.md Outdated Show resolved Hide resolved
@Vergenter
Copy link
Contributor Author

Vergenter commented Aug 7, 2023

Long story short:

syncplay treats links as files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "syncplayClient.py", line 17, in <module>
  File "syncplay\ep_client.pyc", line 8, in main
  File "syncplay\clientManager.pyc", line 9, in run
  File "syncplay\ui\ConfigurationGetter.pyc", line 557, in getConfiguration
  File "syncplay\ui\ConfigurationGetter.pyc", line 471, in _loadRelativeConfiguration
  File "syncplay\ui\ConfigurationGetter.pyc", line 462, in __getRelativeConfigLocations
  File "ntpath.pyc", line 651, in realpath
  File "ntpath.pyc", line 601, in _getfinalpathname_nonstrict
FileNotFoundError: [WinError 161] The specified path is invalid: '\\\\wsl$\\Ubuntu\\home\\vergenter\\ani-cli\\https:\\www054.vipanicdn.net\\streamhls\\f134bc36b9bb59de2ef28a48a7cef6bf\\ep.5.1683732036.1080.m3u8'

The only workaround I found for this is to call it using cmd.exe (PowerShell also has a problem with the url-path).
cmd.exe /C "syncplay.exe"

cmd call and argument(title) with spaces

I cannot use cmd in a way described below because then I cannot handle spaces in the title. WSL loses the ability to use the absolute path when escaping spaces in the title in any way.

vergenter@DESKTOP-JDQ0A50:/mnt/c$ cmd.exe /C "C:\Program Files (x86)\Syncplay\syncplay.exe" "123" --  --force-media-title="123 123"
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

Without a space in the title it works fine...

Solutions
  1. Use the path for syncplay, but it needs to be the Windows path rather than the WSL path, as cmd won't use the WSL paths. This is rejected because Windows syncplay does not add itself to the path.
  2. cd to the path. This is ugly, but it avoids all problems with the title. Additionally, checking dependencies for syncplay this way works correctly.

It should be now ready to review.

Should I modify this part?
https://github.com/Vergenter/ani-cli/blob/ad2b2c00072612d4c4dbd203dc3a6536b37e6cbc/ani-cli#L346-L364

Copy link
Collaborator

@port19x port19x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather not have such large code addition for an unsupported plattform.
We support windows natively.
The expanded matching for a wsl2 uname is welcome, but that's about the extend I'm willing to make concessions for wsl users.

ani-cli Outdated Show resolved Hide resolved
ani-cli Outdated Show resolved Hide resolved
@Vergenter
Copy link
Contributor Author

I'd rather not have such large code addition for an unsupported plattform. We support windows natively. The expanded matching for a wsl2 uname is welcome, but that's about the extend I'm willing to make concessions for wsl users.

Understood. I worked on adding syncplay support for WSL2 because it's on the required list.

However, note that currently syncplay is supported in weird/hacky way:

  1. For some reason, it switches using a different uname.
  2. Syncplay doesn't officially support URLs; it uses file paths as arguments.

@justchokingaround
Copy link
Collaborator

syncplay works with URLs, it just doesn't support m3u8 links

@Vergenter
Copy link
Contributor Author

Vergenter commented Aug 8, 2023

syncplay works with URLs, it just doesn't support m3u8 links

vergenter@DESKTOP-JDQ0A50:~$ syncplay --help
usage: syncplay [-h] [--no-gui] [-a hostname] [-n username] [-d] [-g] [--no-store] [-r [room]] [-p [password]]
                [--player-path path] [--language language] [--clear-gui-data] [-v]
                [--load-playlist-from-file loadPlaylistFromFile]
                [file] [options ...]

Solution to synchronize playback of multiple media player instances over the network.

positional arguments:
  file                  file to play
  options               player options, if you need to pass options starting with - prepend them with single '--'
                        argument

First positional argument is a file and this is how it is used in ani-cli.

ani-cli/ani-cli

Line 258 in d4f9c22

*yncpla*) nohup "$player_function" "$episode" -- --force-media-title="${allanime_title}Episode ${ep_no}" >/dev/null 2>&1 & ;;

Using url in place of file is undocumented behaviour and it fails because of this in WSL.

BTW. Code is ready I applied change proposals.

@justchokingaround
Copy link
Collaborator

Using url in place of file is undocumented behaviour and it fails because of this in WSL.

wym? the "file" that is passed in ani-cli is literally a url. ik it because i implemented it. i'm telling you that links that end with .m3u8 do not work with syncplay, no matter which platform.

have you tested in wsl syncplay with .mp4 links?

@Vergenter
Copy link
Contributor Author

Vergenter commented Aug 8, 2023

wym? the "file" that is passed in ani-cli is literally a url. ik it because i implemented it. i'm telling you that links that end with .m3u8 do not work with syncplay, no matter which platform.

have you tested in wsl syncplay with .mp4 links?

As I previously mentioned WSL2 fails, because of it:
That is from syncplay logs(URL is parsed like path):

FileNotFoundError: [WinError 161] The specified path is invalid: '\\\\wsl$\\Ubuntu\\home\\vergenter\\ani-cli\\https:\\www054.vipanicdn.net\\streamhls\\f134bc36b9bb59de2ef28a48a7cef6bf\\ep.5.1683732036.1080.m3u8'

@justchokingaround
Copy link
Collaborator

does the same thing happen with mp4 files?

@Vergenter
Copy link
Contributor Author

Vergenter commented Aug 8, 2023

does the same thing happen with mp4 files?

If by mp4 you mean for example this:
obraz
Then yes.

FileNotFoundError: [WinError 161] The specified path is invalid: '\\\\wsl$\\Ubuntu\\home\\vergenter\\ani-cli\\https:\\myanime.sharepoint.com\\sites\\chartlousty\\_layouts\\15'

This is filled correctly:
obraz
wsl prefix is not visible there:
obraz
If I start syncplay from windows and manually paste url it works ok.
If I start syncplay from wsl and manually paste url it fails.

@justchokingaround
Copy link
Collaborator

does syncplay even work with any links that are not local files, in wsl?

@justchokingaround
Copy link
Collaborator

even youtube links

@Vergenter
Copy link
Contributor Author

even youtube links

All URL fails using syncplay from wsl.(m3u8 from windows syncplay work ok, I just tested)

FileNotFoundError: [WinError 161] The specified path is invalid: '\\\\wsl$\\Ubuntu\\home\\vergenter\\ani-cli\\https:\\www.youtube.com'

@justchokingaround
Copy link
Collaborator

oh ok, then we ignore syncplay support for wsl

@Vergenter
Copy link
Contributor Author

@justchokingaround
How does in other situation url work at all?
This is how it is handled in syncplay:
https://github.com/Syncplay/syncplay/blob/6b490a40980bd61307ea20ede37fd7e4d2c8073e/syncplay/ui/ConfigurationGetter.py#L556-L557
It is def _loadRelativeConfiguration(self): that handles it
https://github.com/Syncplay/syncplay/blob/6b490a40980bd61307ea20ede37fd7e4d2c8073e/syncplay/ui/ConfigurationGetter.py#L460-L480
I don't undestand how any URL survives that.

@justchokingaround
Copy link
Collaborator

@port19x can you check this please, i haven't used syncplay in a while, and i don't have it installed atm

@port19x
Copy link
Collaborator

port19x commented Aug 9, 2023

@port19x can you check this please, i haven't used syncplay in a while, and i don't have it installed atm

I can once I'm home, but better open a separate issue / ping me on discord because I'll probably forget until the end of the workday

@port19x port19x merged commit ed9d149 into pystardust:master Aug 9, 2023
6 checks passed
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.

None yet

3 participants