Explanation of changes in 4.0

[UnixCro]

Wait a second

I'll edit the post later, which is now a bit older, at the latest when I realized how everything escalated and that this Github error was even pinned.

I really let my emotions out here. And I don't want to drastically correct my posts just because they've been more publicized now.

It could be that I speak very inappropriate about the author and also use inappropriate words. I explained all the changes of PyInstaLive 4.0.X and I complained about most of them because until now unfortunately Version 4.0 is bad. And I also mentioned in detail why you shouldn't load this version, but only when the older, most stable Version 3.2.4 shouldn't work anymore for some reason.

In no way do I want to portray the author badly. I'm glad he exists because he has created things that have helped me tremendously in my life, like downloading Snapchat videos as well as loading Instagram live streams.

I only complained a lot because PyInstaLive is one of my favorite programs and I had a lot of memories with it. And out of nowhere an update of PyInstaLive V4.0.X appears which was the biggest shit and hurt me a lot.

Nevertheless, I think it's worth looking over here and reading through everything.

Also, maybe get some popcorn to drink before you leave it all. I hope you enjoy it.

---

Hi Dirk,
This isn't a bug or anything else I want to report, just something that seems unclear to me.
I find the program breathtaking, which I have already mentioned in other posts and use it every day. However, I don't find Version 4.0 really successful. I don't understand why you changed the pyinstalive.ini file so drastically badly?

Old:

[pyinstalive]
username = johndoe
password = grapefruits
download_path = 
download_lives = True
download_replays = True
download_comments = true
show_cookie_expiry = True
log_to_file = True
ffmpeg_path = 
run_at_start =
run_at_finish =
use_locks = True
clear_temp_files = False
do_heartbeat = True
proxy = 
skip_merge = False

New:

[pyinstalive]
username = johndoe
password = grapefruit
download_path = 
ffmpeg_path = 
download_comments = True    
cmd_on_started =
cmd_on_ended =
clear_temp_files = False
use_locks = True
no_assemble = False
log_to_file = True

Where is download_replays, show_cookie_expiry ?

Why the name run_at_start, run_at_finish, changed in cmd_on_started, cmd_on_ended. There is no sense? cmd?

Where is clear_temp_files, do_heartbeat, proxy.?

And why do you swap clear_temp_files and use_locks before it was sorted.

no_assemble, Bro skip_merge was the best. And log_to_file was in the old file over skip_merge

All these things we needed.

Where is the help? Old Version 3.2.4 https://github.com/UnixCro/PyInstaLive

You can find a list of frequently asked questions here.

You can find a list of available commands and an explanation of the configuration file here.

Downgrade to 3.2.4!

Sorry but I think that Version 4.0 has become completely shit.

I urge everyone not to download this version and download V3.2.4 instead.

I studied PyInstaLive in detail and gave presentations about it. Even if you wouldn't expect it from my spelling, it's probably because of the frustration. The people who are new don't know what it was like before.

I will explain PyInstaLive in detail, in detail and also explain why the parts left out are so important in Version 4.0.0 and why they help us more.

pip install git+https://github.com/dvingerh/PyInstaLive.git@3.2.4

[dvingerh]

You should be very grateful I pushed out a very important update all for free but instead you basically spit in my face and call it complete shit because I didn't pander to your wishes. Very sad and disrespectful!

I will now explain the changes for clarity.

I stripped it down to the bare essentials so that there is less chance of features breaking over time and interfering with the rest of the script. 4.0.0 now fully uses the web API which is more reliable than using third party packages which depend on the app API. And it's less effort to make changes to the API related code if anything no longer works properly.

• cmd is shorthand for command. Not much else to say about that.
• download_replays was removed because "Replays" no longer disappear after 24 hours and they are now categorized as normal videos on an user's profile. Ergo it's out of scope for this script which focuses on livestreams.
• show_cookie_expiry still exists, the expiration date will now always be shown.
• clear_temp_files still exists, it still behaves the same way it always has.
• do_heartbeat still exists, it's now always enabled to obtain necessary information about the livestream status (you can remove it in a fork but it will cause various bugs).
• proxy was removed because I don't have any proxies to test with and probably wasn't used that much.
• FAQ and MOREHELP were heavily outdated. Most of the available configuration and arguments are self explanatory.

Some other configuration entries ended up being renamed while I rewrote the entire script. No big deal.
The order in which configuration entries are listed in pyinstalive.ini doesn't matter.

The only 'big' feature that was lost is checking if any users from your following list have any available livestreams. I may add it in a future update but as you know active development has ended and your disrespectful issue does not encourage me to further work on it.

[UnixCro]

Hello Dirk,
thanks for your quick reply.

I think you misunderstood my post. The problem is that I don't think Version 3.2.4 poses any problems at all and I found the options that PyInstaLive still used there extremely useful. I really don't understand why they bother to degrade PyInstaLive and then portray me as a very bad person, just because I tell the truth that the program has gone bad.

You should be very grateful I pushed out a very important update all for free but instead you basically spit in my face and call it complete shit because I didn't pander to your wishes. Very sad and disrespectful!

Yes, but I, as a daily PyInstaLive user and honorer, am not at all grateful. Most people don't care if something got worse or better. But those who have benefited from something so much, they honor something down to the last detail, and if the developer then makes crap out of the program, what should I be thankful for?
They obviously degraded the program. Of course you are the author. You decide what to do. But it's sad. PyInstaLive was more than perfect they made it worse.

I stripped it down to the bare essentials so that there is less chance of features breaking over time and interfering with the rest of the script.

That's not true. PyInstaLive has not been exposed to any vulnerabilities anywhere. Version 3.2.4 has been around for a long time. For example, whether it should be displayed when the cookie session expires or not (show_cookie_expiry) does not change the fact that PyInstaLive no longer works. Version 4.0.0 does not offer any advantages.

4.0.0 now fully uses the web API which is more reliable than using third party packages which depend on the app API. And it's less effort to make changes to the API related code if anything no longer works properly.

I think they are trying to talk good here version 4.0.0. If you mean that version 3.2.4 is a privacy vulnerability, which I actually can't quite understand because we only download live streams ...
Alright then it wouldn't have been a problem, if they introduced the privacy improvement, but the rest would have left unchanged.

cmd is shorthand for command. Not much else to say about that.

But what about run_at_start. Don't think it sounds better than cmd_on_start. I mean we grew up with run_at_start. Did you really have to change it? Every PyInstaLive version had this argument in its name. Every trusted user directly related this argument to PyInstaLive. Why are you changing that?

download_replays was removed because "Replays" no longer disappear after 24 hours and they are now categorized as normal videos on an user's profile. Ergo it's out of scope for this script which focuses on livestreams.

Didn't you even mention in your old ReadMe file that people with unupdated Instagram app can still post replays?
You didn't have to remove that either. PyInstaLive was built by you intelligently enough at that time. It checks existing replays, if there aren't any it doesn't download them either. The advantage, however, it offers the possibility ...

show_cookie_expiry still exists, the expiration date will now always be shown.

And why is it always displayed, can't you leave it as is to be able to decide for yourself whether it should be displayed or not. PyInstaLive already has a lot of output anyway, the terminal window is already well filled.

do_heartbeat still exists, it's now always enabled to obtain necessary information about the livestream status (you can remove it in a fork but it will cause various bugs).

That's not right at all. Disabling a heartbeat has never caused any problems, even the old message "Could cause performance degradation" when you turned it off back then is absolutely wrong and we discussed that in another Github issue back then, if you want I'll look for it for you Out.

do_heartbeat was the most important function that PyInstaLive had. They have no idea how nice it was to download live streams without the owner knowing they were watching. There was someone with such an extreme advantage, you can't believe it.

Just imagine what your girlfriend would say if she were watching and what she would say if she wasn't watching.

livestream_dl always had no heartbeat. PyInstaLive had still the opportunity to exhibit it back then. But now it's always on and I hate version 4.0.0.

proxy was removed because I don't have any proxies to test with and probably wasn't used that much.

But why remove it? They have changed so much and weren't able to quickly pull any nh proxy from the network and test whether it works with the new version. Instagram is notorious for blocking. PyInstaLive 3.2.4 was smart and was able to do something about it. Other users in the Github issue also praised the proxy feature for getting banned. They even mentioned back then in the ReadMe file that if you write a script to monitor a live stream for minutes, you might get banned and use the proxy. Simply omitted in version 4.0.0. I hate version 4.0.0!

FAQ and MOREHELP were heavily outdated. Most of the available configuration and arguments are self explanatory.

It would have continued to work to this day, if the replays thing had been removed. One can really argue about whether it is still relevant now. If I'm honest. But many things were explained in the ReadMe file, now you can't find anything anymore, only that the developer has switched to version 4.0.0.

The order in which configuration entries are listed in pyinstalive.ini doesn't matter.

And why don't you leave the order as it was. Should it confuse us even more? You are aware that PyInstaLive always write a pyinstalive.ini with the wrong arrangement.

The only 'big' feature that was lost is checking if any users from your following list have any available livestreams. I may add it in a future update but as you know active development has ended and your disrespectful issue does not encourage me to further work on it.

If you hadn't switched to version 4.0.0 it wouldn't have happened either.

Apart from that, the parameter was the most important function of PyInstaLive. The function that made the main difference between livestream_dl. Just imagine yourself. There are currently 5 people who are live. Do you enjoy opening a new terminal tab every time and typing pyinstalive -d for each person, where there are also time delays because you have to type the command every time and have to look up what that person's name is exactly on Instagram every time and break at spelling mistakes the script or do you prefer to type pyinstalive -df where pyinstalive immediately notices who is live and downloads them all at the same time in the background.

---------------------------------------------------------------------------
[I] PYINSTALIVE (SCRIPT V4.0.1 - PYTHON V3.8.9) - TT-MM-JJJJ HH:MM:SS AM|PM
---------------------------------------------------------------------------
[W] Could not find configuration file, creating a default one.
[I] A new configuration file has successfully been created.
---------------------------------------------------------------------------

I like the older post better ([W] Edit the created 'pyinstalive.ini' file and run this script again.)
because here the ignorant gets exactly the information about which file he has to edit exactly.

The same applies as soon as you run pyinstalive the 2nd time.

V4.0.X [E] No known arguments were provided.
V3.2.4 [E] Please use a download method. Use -h for more information.

We're told that we can use -h if we run into trouble.

Fuck version 4.0.0

In version, not only the -df parameter has been removed, but also --no-lives, which means that not only do we have to download the comments, but we always have to have the video with us.

Removed the ability to better organize the downloaded files --organize.

Changed the parameter from --assemble to --generate-videos which sucks.

Why the hell are you probably wondering? I think the comment downloader --generate-comments is called the same.

But that's not how PyInstaLive works, while --generate-comments only needs the segmentfiledirectory.json file to generate a comment file, --assemble needs the segmentfiledirectory AND the associated JSON file. The commands have different requirements, so they should not have the same names!

Version 4.0.0 sucks and I ask you not to be silent and accept the change like this!

The author didn't bother at all in version 4.0.0. why? He has confirmed that he no longer cares about the script because he no longer uses it himself. And you can tell. The script is bullshit. I challenge everyone here to do so.
UNINSTALLED VERSION 4.0.0. IT DOES NOT DESERVE ATTENTION

---

I don't mean to badmouth you, quite the opposite. I use PyInstaLive and PySnapStories every day. But I don't know what was wrong with them from version 3.2.4 that they made PyInstaLive so bad.

Like I said you decide what you do, I just want to give my opinion on what you make of it is up to you. Luckily I still have a fork from the old version.

I am happy to offer you money to support the development as in Version 3.2.4. If I see a bitcoin address, I'll send you something.

Best regards
UnixCro

[UnixCro]

What do you think about the proposal to reset everything to the state of version 3.2.4 and to simply install it with the web API if you have such big data protection problems? Or is something wrong? Can I help you in any way? What can I do for you?
Best regards
UnixCro

[dvingerh]

It doesn't have anything to do with data protection, I switched to the web API because plenty of people were having authentication issues with the app API, and the app API can break completely at any time with no way for me to fix it

There will be no rollback. You're not forced to update to the latest version, you can keep using 3.2.4 for as long as you want, all the older versions are available by tag anyway https://github.com/dvingerh/PyInstaLive/tags all you need to do to install a different version is specify the version tag in the pip command

I don't use this script anymore, no reason for me to invest any more effort into adding the extra features the old version has, my only goal was making sure the core functionality keeps working (ability to download livestreams)

Maybe some other time i'll readd the features and look for a workaround for the heartbeat request (which I have to rely on now to get livestream health status unlike the app API) and maybe readd some features that were lost

[UnixCro]

I won't comment on that now... Anyone who has read through this, just trust me, just don't use Version 4.0.0 ...

pip install git+https://github.com/dvingerh/PyInstaLive.git@3.2.4

[pplswr]

do_heartbeat still exists, it's now always enabled to obtain necessary information about the livestream status (you can remove it in a fork but it will cause various bugs).

@dvingerh sorry for the ping, but does this means that in v4.0 my user will appear as an active viewer even if heartbeat is set to false?

[dvingerh]

Yes, and heartbeat can't be set to false because I need to rely on it (for now) to obtain the livestream status (whether it's still active or interrupted, etc)
You can fork the project and remove the function altogether but it'll cause buggy/weird behavior in return
There's a different endpoint I can use to get the livestream status but it's not meant to be called every few seconds and will likely just result in rate limiting or a blocked account. Need to do more testing for that sometime

So you can either choose to keep using the older version whose API reliability is sketchy at best but has more features or use this version which is less prone to break in some way but has less features

[Shmi911]

I won't make an angry statement, because I'm feeling lucky to have this script.
But I will stay @ 3.2.4 for now aswell and can only recommend that.

"do_heartbeat" (false) is very important to me. It has been discussed already. It makes no sense to appear as an "active user", because you can't interact with the person that is livestreaming. (unless you actually watch + use the script at the same time)
I assume most ppl don't want to be shown as a viewer.

"checking if any users from your following list have any available livestreams" you named it. It's a big loss in the newest version 4.0.0. This function makes it very easy without any or much scripting/coding to monitor for ongoing live streams.

My system is automatically running "--download-following" whenever Instagram sends a live notification through Chrome browser which is also triggering windows notifications. To me it would be a difficult task to filter what exact account is livestreaming and only use download function for that account.

So, long story short. I can only hope for these 2 essential functions to be implemented again.
I'm happy to see any work/developement/maintenance put into pyinstalive.

[dvingerh]

I already made a few changes bringing those features back + proxy, just not committed yet
Needs a bit more testing but I'll commit it later today so you can give it a go yourself

To install v4 with the very latest changes just omit the version tag from the install command

[UnixCro]

My system is automatically running "--download-following" whenever Instagram sends a live notification through Chrome browser which is also triggering windows notifications. To me it would be a difficult task to filter what exact account is livestreaming and only use download function for that account.

That's extremely cool. That would save me a lot of work. Would you be so kind and tell me how something like that?
Best regards
UnixCro

[dvingerh]

Made a beginning for re-implementation of

• --download-following argument
• proxy configuration file entry (e.g. proxy = https://197.246.171.158:8080)
• send_heartbeat configuration file entry (e.g. send_heartbeat = True)

Install and test with latest commits using pip install git+https://github.com/dvingerh/PyInstaLive.git

[UnixCro]

Wow Dirk! Thanks for that man. But the first thing that strikes me is some weird things.

In V3.2.4

$ pyinstalive
---------------------------------------------------------------------------
[I] PYINSTALIVE (SCRIPT V3.2.4 - PYTHON V3.8.9) - TT-MM-JJJJ HH:MM:SS AM/PM
---------------------------------------------------------------------------
[W] Could not find configuration file, creating a default one.
[W] Edit the created 'pyinstalive.ini' file and run this script again.
---------------------------------------------------------------------------

In V4.0.X

---------------------------------------------------------------------------
[I] PYINSTALIVE (SCRIPT V4.0.0 - PYTHON V3.8.9) - TT-MM-JJJJ HH:MM:SS AM/PM
---------------------------------------------------------------------------
[E] No known arguments were provided.
---------------------------------------------------------------------------

The message that a default configuration file was created is missing. No configuration file was made …

---

$ pyinstalive -h
---------------------------------------------------------------------------
[I] PYINSTALIVE (SCRIPT V4.0.0 - PYTHON V3.8.9) - 06-17-2022 10:11:57 AM
---------------------------------------------------------------------------
usage: pyinstalive [-h] [-u] [-p] [-d] [-df] [-i] [-cl] [-cp] [-dp] [-dc] [-gc] [-gv] [-na]

PyInstaLive 4.0.0 using Python 3.8.9

optional arguments:
  -h, --help                  show this help message and exit
  -u , --username             Instagram username to login with.
  -p , --password             Instagram password to login with.
  -d , --download             Instagram username whose livestream you want to download.
  -df, --download-following   Check for available livestreams from people you're following.
  -i, --info                  Shows information about PyInstaLive.
  -cl, --clean                Clean the current download path of all temporary files.
  -cp , --config-path         Override the default configuration file path.
  -dp , --download-path       Override the default download path.
  -dc, --download-comments    Download livestream comments. Overrides the configuration file setting.
  -gc , --generate-comments   Generate a comments log file. Requires a livestream JSON file.
  -gv , --generate-video      Assemble downloaded livestream segments into a video file. Requires a livestream segments folder.
  -na, --no-assemble          Do not assemble the downloaded livestream segments into a video file. Overrides the configuration
                              file setting.

I would move the --info and --clean parameters a bit more to the right.

---

[pyinstalive]
username = johndoe
password = grapefruits
download_path = 
ffmpeg_path = 
download_comments = True    
cmd_on_started =
cmd_on_ended =
clear_temp_files = False
use_locks = True
no_assemble = False
log_to_file = True

I don't know where send_heartbeat (V3.2.4 do_heartbeat) and proxy is. Maybe extra like this?

Ok, I have now established that either you leave out both or you add both. You can't choose. I would suggest always including these arguments as a standard.

---

Also, the quality has changed for me. But I can't confirm it 100% and ask others to test it too. My computer is going crazy with the constant pip install+git switching.

1.mp4

In V4.0.X it seems to me that the picture gets warmer. But I'm not sure …

---

Even if I don't like the ending .dat, before .lock. And even if there is no --organize parameter. And even if I don't like the PyInstaLive output at all as in V3.2.4. (But V4.0.X is damn fast). And even though many other things have been changed, which I don't like, see the reasons above... Am I grateful that you're trying to improve <3

Best regards
UnixCro

[dvingerh]

The message that a default configuration file was created is missing. No configuration file was made …

This has been fixed

I would move the --info and --clean parameters a bit more to the right.

I have no control over this

Even if I don't like the ending .dat, before .lock.

The .dat file is your saved login session. Don't delete that. The .lock files still exist as usual

Also, the quality has changed for me. But I can't confirm it 100% and ask others to test it too.

Possible. It's got to do with which metadata the script uses to download the stream. The quality should remain the same, but if things look significantly different (worse) lmk

Just pushed 4.0.1: https://github.com/dvingerh/PyInstaLive/releases/tag/4.0.1

[Infinitay]

Gave all this a read and just dumbfounded by the sheer entitlement and ignorance. Props to you for continuing to implement the changes especially after all that.

That being said, perhaps you should consider adding the ability to sponsor your GitHub or donation links such as a wallet address for those who wish to support you to further development for this tool. After all, with so much nitpicking and complaints I've read in this thread, probably should be charging at this rate for spending your time after you've already mentioned you're no longer actively working on this.

[dvingerh]

I prefer positive feedback over donations, thanks
Re-implementing the missing features was less work than anticipated and I would have done it eventually anyway so I just got it over with

[hymnzzy]

-df command is not working in 4.0.2. Below error is thrown:

[dvingerh]

-df command is not working in 4.0.2. Below error is thrown:

No problems here with both the executable and when installed with pip
Have you done as the error says?

[hymnzzy]

-df command is not working in 4.0.2. Below error is thrown:

No problems here with both the executable and when installed with pip Have you done as the error says?

Yes. No problem with any other command. Maybe this error is because I'm using a windows machine?

[dvingerh]

I also use a Windows machine so that's not the problem.
What's the output of the command where pyinstalive?

[hymnzzy]

[dvingerh]

I always found the default/MS store installation of Python and pip to cause problems so I would recommend uninstalling it and using the normal installer from here: https://www.python.org/downloads/
Make sure to check the relevant boxes in the installer (like adding Python to PATH and installing pip in the extra options menu)

[Shmi911]

-> tested v 4.0.2
--> downloaded 1 livestream
---> now my acc is shadowbanned or something?
Message in command line:
[E] Could not get livestream information: Expecting value: line 1 column 1 (char 0)
Message in web version when I click on any live stream:
"This webpage is not available"
(And yes, I tested watching those lives with another account on the web version and it works. It does not display "This webpage is not available")

While downloading with another account i received the following message:
Exception in thread Thread-1: Traceback (most recent call last): File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\threading.py", line 954, in _bootstrap_inner self.run() File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\threading.py", line 892, in run self._target(*self._args, **self._kwargs) File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\site-packages\pyinstalive\helpers.py", line 183, in handle_tasks_worker globals.download.update_stream_data(from_thread=True) File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\site-packages\pyinstalive\download.py", line 279, in update_stream_data stream_heartbeat = api.do_heartbeat() if globals.config.send_heartbeat else api.get_stream_data() File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\site-packages\pyinstalive\api.py", line 45, in get_stream_data return json.loads(response.text) File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\json\__init__.py", line 346, in loads return _default_decoder.decode(s) File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\json\decoder.py", line 337, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "C:\Users\Username\AppData\Local\Programs\Python\Python39\lib\json\decoder.py", line 355, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

I don't know if that helps or is just another random error.
Anyways, that 2nd account is now on "challenge required" (after 1 download).

I already reinstalled v 3.2.4.
Now downloading with my first account works even when I can't watch in the web version. I can watch in the mobile app. So the api mode still works.

No idea what causes all those problems with the newest version. I didn't expect this at all.

---

Edit1: I know being detected by IG is usually not fixable or not an issue of the script. But, when being suspicious to IG so quick (after 1 download), it's obvious that I stay with the older version (3.2.4). I haven't been "challenge required" for more than a year with the older version. In fact not even a single time, since the script only starts automatically when a live notification of IG pops up.
I just want to see if anyone else has same issues like me. Maybe my problems were just a coincidence?
The only reason why I upgraded to test the new version, was that I think that the no heartbeat function does not work all the time in v3.2.4.