Closed Vergenter closed 1 year ago
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
no need to add that to the README
syncplay
treats links as filesDuring 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"
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...
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.cd
to the path. This is ugly, but it avoids all problems with the title. Additionally, checking dependencies for syncplay this way works correctly.
Should I modify this part? https://github.com/Vergenter/ani-cli/blob/ad2b2c00072612d4c4dbd203dc3a6536b37e6cbc/ani-cli#L346-L364
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:
syncplay works with URLs, it just doesn't support m3u8 links
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.
https://github.com/pystardust/ani-cli/blob/d4f9c22d5dad99a7c0ff169c89521d2976dc3cff/ani-cli#L258-L258
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.
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?
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'
does the same thing happen with mp4 files?
does the same thing happen with mp4 files?
If by mp4 you mean for example this:
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:
wsl prefix is not visible there:
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.
does syncplay even work with any links that are not local files, in wsl?
even youtube links
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'
oh ok, then we ignore syncplay support for wsl
@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.
@port19x can you check this please, i haven't used syncplay in a while, and i don't have it installed atm
@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
Pull Request Template
Type of change
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:
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)
Moreover, using uname -s to switch cases for syncplay is insufficient and requires modification.
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
[x] bumped version
-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[x] all providers return links (not necessarily on a single anime, use debug mode to confirm)
-h
help info is up to dateAdditional Testcases