search

beardypig / streamlink-portable

A script to build a portable version of Streamlink for Windows
Apache License 2.0
77 stars 18 forks source link

404 on stable portable version + other issues... #14

Closed Vangelis66 closed 3 years ago

Vangelis66 commented 6 years ago

Hello @beardypig 😃 I do hope you're OK! Revisiting streamlink and your splendid side-project here, after many months of absence...

Having always been a portable version fan, I'm not (that) affected from https://github.com/streamlink/streamlink/issues/1476 ; however, I totally relied upon your precompiled portable nightly versions, that used to show up in your AWS repo... The last version obtainable from there is streamlink-portable-0.5.0-20170510-g9ad8bb2-py3.5.2-win32 . I now realise this is because of https://github.com/beardypig/streamlink-portable/commit/2665746f2b4068406f70c8ba2ee5a1e029be2e14; over to Bintray, then 😉

First thing to notice is there's no retention in that repo (i.e. several days' worth of previous builds), but I suspect this was done out of bandwidth considerations... Second thing is there's no indication in the hosted/downloaded package of the code snapshot it is derived from (as was the case with the AWS repo); from README.md:

The portable zip files are build from the master branch of streamlink/streamlink

So, am I to assume that if I download now, I'll end up with streamlink-portable-0.10.0-20180227-g91d3e77-py3.5.4-win32 (in accordance with the AWS naming template)? And my real question is, can your build/bintray uploading script be revised as to create an informative nightly package filename, along the lines of what was previously in place for AWS? I certainly am oblivious to the bintray specifics, please pardon me if this is an invalid request :blush:

Stable (aka release) portable versions:

I, too, used to get those from your AWS repo, the latest that can be fetched from there is streamlink-portable-0.5.0-py3.5.2-win32 Again, https://github.com/beardypig/streamlink-portable/commit/2665746f2b4068406f70c8ba2ee5a1e029be2e14 implies that stable portable releases are now hosted on GitHub; but the latest pre-compiled stable release to be found there is streamlink-portable-0.7.0-py3.5.2-win32 from last July 2017 (BTW, that should've been labelled as "streamlink-portable-0.7.0-py3.5.3-win32", as it contains Python 3.5.3). Additionally, the main streamlink page links to here, where no stable package resides 😢 ; even worse, README.md on this repo informs that

A stable version is also available, based on the 0.10.0 tag of streamlink:

but both included links return a 404 from GitHub... :confused: Obviously, there's something gone awry with stable releases on GitHub :anguished:

One final, important to me, issue: My OS is (still, by necessity) Windows Vista SP2 32-bit, but fully updated with post EOL M$ updates prepared for Vista's server counterpart (WS2008SP2, more at MSFN); I am not running a bot! I don't know what your personal intentions are towards Vista support, you can easily bail out by citing vendor's EOL, but, just so you know, Python 3.5.x and even 3.6.x is still Vista SP2 compatible, so I guess the streamlink script itself is too:

Windows Vista requires at least SP2 to be installed

The unfortunate fact is that https://github.com/beardypig/streamlink-portable/commit/8de5aafbded25ae7d785ef4af7f0d12b31ccbeef has broken your portable builds (nightly+stable) on Vista (SP2); at least on my laptop (en-US is the OS locale), executables (including batch files) with cp65001 don't seem to start/run normally when invoked from the cmd line/from within .bat|.cmd files; don't ask me why, I've searched this issue a lot (currently also afflicts MP4Box.exe binaries on Vista) but found nothing concrete (or a workaround I could apply on my system); sure thing is, this issue does not manifest on Windows 7 and higher... So, I have to comment out this commit on the downloaded streamlink.bat file: 

@echo off
::REM Change the code page for UTF8
::chcp 65001 >NUL
::set PYTHONIOENCODING=cp65001
"%~dp0\python\python.exe" "%~dp0\streamlink-script.py" --ffmpeg-ffmpeg "%~dp0\ffmpeg\ffmpeg.exe" --rtmp-rtmpdump "%~dp0\rtmpdump\rtmpdump.exe" --config "%~dp0\streamlinkrc" %* --no-version-check

to be able to run your portable builds on my OS (which I do by creating a shortcut to cmd /k Streamlink -V && Streamlink, saving it as Run_StreamlinkPortable.lnk, placing it alongside your batch file and clicking that when required...)

Thanks a bunch for the code you contribute to the streamlink project, for this effort here (portable win-builds) and for your patience and understanding while reading this lengthy report! :heart:

Best wishes, Vangelis

beardypig commented 6 years ago

Thanks for the report @Vangelis66 :)

I have been remiss in uploading the builds to GitHub, it should be automatically uploaded to GitHub releases... I'll fix that now. Update: Fixed now The way BinTray is setup it just overrides the last version, the AWS way was better, but it was too expensive to host I'm afraid. Once we have a better solution for the main streamlink repo, I will do the same thing here :)

I will take a look at the encoding issue that you have on Vista, does chcp 65001 also break it? or just set PYTHONIOENCODING=cp65001. Would you be able to run both of those commands in a cmd.exe shell and show me what is returned? I don't have Vista, so this might take a while to debug :)

beardypig commented 6 years ago

Also, could you run the command ver and show me what is returned?

Vangelis66 commented 6 years ago

Hi, thanks for your swift response! 👍

it should be automatically uploaded to GitHub releases... I'll fix that now. Update: Fixed now

Thanks a mil! Just grabbed the streamlink-portable-0.10.0-py3.5.4-win32.zip package...

The way BinTray is setup it just overrides the last version

OK, this explains why only one nightly version - the very latest (current HEAD?) from streamlink master branch - is hosted on BinTray; but, as I already said, streamlink-portable-latest-win32.zip isn't very descriptive/informative of what one downloads; if I redownload a few days later, it will still have the same file name (but potentially different content, if changes were committed upstream); and will again result in the same streamlink folder once decompressed. I just saw your recent commit https://github.com/beardypig/streamlink-portable/commit/ad87735825782a7d048cc5ec5da0b51b68fe7d01, which appears relevant to my query; but I don't fully understand code, can BinTray host the only one nightly package with a
streamlink-portable-0.10.0-20180227-g91d3e77-py3.5.4-win32 filename template, or does it always have to be streamlink-portable-latest-win32?

I will take a look at the encoding issue that you have on Vista

Thanks already for not giving up!

does chcp 65001 also break it? or just set PYTHONIOENCODING=cp65001?

Apologies, I'll again be more verbose! I first encountered a similar type of breakage on Vista with the CLI tool MP4Box.exe (I bet you're aware of it); recent GPAC nightly (windows) binaries couldn't be invoked from within batch files on my system; after a lengthy troubleshooting on my own, I found the culprit commit to be https://github.com/gpac/gpac/commit/7254f9980f339cb309656f41cbabf8406b593e5b, specifically lines 

+   /* force windows console codepage to utf8 to display (some, but not all) characters properly */
+   SetConsoleOutputCP(65001);

Those MP4Box nightly binaries do not manifest this issue on Win7 (I borrowed sister's laptop to check), so this appears to be a Vista limitation 😭 FWIW, if I want to run latest MP4Box code on my machine, I have to fetch latest source from GitHub, revert those lines and then compile a static binary on my own (via an older version of the native MSYS2 compiler, that still works on Vista 32-bit).

The exact issue with your more recent portable offerings is as follows (I'll use the last stable version I just grabbed as an example):

  1. I open a Command Prompt Window in the directory where your provided streamlink.bat file resides
  2. If I type streamlink and hit ENTER, nothing happens/is displayed
  3. If I comment out all three lines in the batch file 
    ::REM Change the code page for UTF8
::chcp 65001 >NUL
::set PYTHONIOENCODING=cp65001

    save the changes and re-issue streamlink in the CPW, all is OK:

cmd

If I uncomment only chcp 65001 >NUL

::REM Change the code page for UTF8
chcp 65001 >NUL
::set PYTHONIOENCODING=cp65001

then again things break (top CMD window in screengrab); if I only uncomment the PYTHONIOENCODING env var 

::REM Change the code page for UTF8
::chcp 65001 >NUL
set PYTHONIOENCODING=cp65001

then things work (bottom CMD window in screengrab); so it would appear that only 

chcp 65001 >NUL

is responsible for my predicament...

While researching this issue for MP4Box, I came across the following SO article: how-to-use-unicode-characters-in-windows-command-line Some relevant comments from there: 

chcp 65001 is very dangerous. Unless a program was specially designed to work around defects in the Microsoft’s C runtime library (or uses a different CRTL), it would not work reliably.

Note there are serious implementation bugs in Windows's code page 65001 support which will break many applications that rely on the C standard library IO methods, so this is very fragile. (Batch files also just stop working in 65001.) Unfortunately UTF-8 is a second-class citizen in Windows. – bobince Dec 29 '11 at 21:51
(and ones following that very comment)

It is highly probable MS improved their cp65001 support on Win7+, but I think I am hit on Vista by the "Batch files also just stop working in 65001" bug... 😭

Would you be able to run both of those commands in a cmd.exe shell and show me what is returned?

chcp 65001 => cmd set PYTHONIOENCODING=cp65001 => nothing is printed in the CPW

Also, could you run the command ver and show me what is returned?

Sure thing, but I already told you that...

ver

i.e. WinVista SP2 (x86)

I don't have Vista, so this might take a while to debug :)

This is understandable; though I do remotely recall you mentioning a Vista VM, where you tested your FFmpeg compile... As for debugging, as long as an easy fix is available for me to get things working, I'm happy already; perhaps you should mention this fix somewhere in this repo for fellow Vista users; what we lack in numbers, we have a surplus of in dedication to that mistreated OS...

My genuinely best wishes

beardypig commented 6 years ago

Thanks for the reply @Vangelis66.

The BinTray builds are overwritten with the latest version mainly due to my laziness, it's easier to have one version and update the files than create a new version every day... I have a bit more experience with BinTray now, so I might switch back to a versioning style more like the AWS hosted ones.

The reason I wanted you to run ver was so I could see exactly what is returned, so I can put in a special case for Vista :) I used to have a Vista VM, and I could probably recreate it, but time is an issue :)

Kein commented 5 years ago

Same issue now with latest portable. Main version is on 1.2.0 now, think you can update?

beardypig commented 5 years ago

@Kein sure. I will see about automating this better with GitHub actions and try to come up with a better solution.