[JDmurphy]

Originally Posted by Jiaz

I just want to make clear that we don't force them.

I just wanted to make clear that I didn't mean "forced" as in "required before the user is allowed to continue" (the definition you were referring to that was apparently understood) but as in "auto-installed in the background without any notification" (the phrasing from the knowledgebase article you linked which I had already found earlier before referencing it in my OP).

Originally Posted by Jiaz

the plugin system is able to load/exchange plugins without a java restart being required

This should be the meaning of

Originally Posted by JDmurphy

"pushed without user interaction/notification"

if I'm not mistaken. The ability to customize the update settings is very interesting! I take no issue whatsoever with the default behavior though, the only reason for mentioning this was to convey right away that I'm aware plugin fixes can be applied in the background so that JDownloader can directly make use of them while core updates do require a restart.

Originally Posted by JDmurphy

do I have to read it as: "Due to changes in the player.js library the JD youtube plugin wasn't working properly, and a core function had to be fixed to make the plugin work again while fixing the plugin itself wasn't required."

Originally Posted by Jiaz

The bugfix was outside of the plugin, within another part of JDownloader. But without this fix, the plugin was/is broken in meaning of not working as wished.

Is there any difference between the two that I might not be aware of which needed clarification?

Originally Posted by Jiaz

Most likely because they were rolling out new player around the same day.

Not only that, but even around the same time. Which is why most if not all users reporting the fix to be working would most likely have experienced download speeds going back to normal without installing the update - just like me, as shown in the screenshot attached to my last post.

FYI, the same thing happened today again:

After installing the first update from Sun Sep 04 13:20:37 (build #46668) yt dl speeds were still slow.
Later today, speeds went back to normal while I was still on that exact same build, JD running continuously, no restarts.
In the evening, I installed the second update from Sun Sep 04 16:07:28 (still build #46668) which didn't make a difference as download speeds were already back to normal as also reported earlier by users in this thread.

[GNIREENIGNE]

Hello.

I am experiencing a strange issue that I have not seen before. Perhaps this is something simple that I have overlooked. I apologize, if so.

I have a particular video that is broken out into chunks, and I am not able to save off the entire video:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

Any suggestions?

I would not normally download such a video, but this particular video keeps buffering for some reason, making it difficult to watch. I have a fiber connection, so this should not be happening.

Thank you for your hard work. I really appreciate it.

[jellytot]

Can JDownloader download **External links are only visible to Support Staff**this video? When I give that URL to JD, it would download a 239KB MP4 file (it should be a few GB in size). I tried again later, and linkgrabber now won't add the video at all. The other most-recent videos in this channel download normally/fine in JD.

[goldensun87]

Originally Posted by GNIREENIGNE

Hello.

I am experiencing a strange issue that I have not seen before. Perhaps this is something simple that I have overlooked. I apologize, if so.

I have a particular video that is broken out into chunks, and I am not able to save off the entire video:

**External links are only visible to Support Staff**...

Any suggestions?

I would not normally download such a video, but this particular video keeps buffering for some reason, making it difficult to watch. I have a fiber connection, so this should not be happening.

Thank you for your hard work. I really appreciate it.

Maybe your video is/was a live stream that was still live? I, personally, have never attempted to save a still live stream with JD. I have, however, attempted to grab and save a long stream which had just ended, and in that instance, JD cannot grab the complete video, because YT has not completed processing the video yet.

YT also has a Premiere system, which is sort of a cross between traditional upload and live stream. For a Premiere, the video is fully uploaded, but is not made "live" until the scheduled date and time. When the video goes live, the duration bar has no definite time, but viewers can live chat while watching, and the traditional comments are not active while the video is live.

I believe, while a Premiere is live, JD cannot grab the video. Now, since a Premiere, unlike a Live Stream, has a set duration, the Live Chat will automatically disable after the Premiere finishes, and after reloading the page, the traditional comments will be active, the Live Chat which was recorded, will replay over the duration of the video, and if the Premiere was not too long, then JD should, almost immediately, be able to grab the video.

[Jiaz]

Originally Posted by JDmurphy

After installing the first update from Sun Sep 04 13:20:37 (build #46668) yt dl speeds were still slow.
Later today, speeds went back to normal while I was still on that exact same build, JD running continuously, no restarts.

The update was released sunday at 13.20 o'clock. But it's unpredictable when/if existing links in list will benefit from the update to have better speeds because only if cached links are expired/failed then JDownloader will reprocess them and be able to incorporate the fix. I have prepared handling for auto refreshing links but this is not ready yet.

Originally Posted by JDmurphy

Is there any difference between the two that I might not be aware of which needed clarification?

I just wanted to explain that in case the issue/bugfix is within a plugin only, it can be fixed/updated(with the plugin only advantages in mind) and doesn't require/depend on any core changes. But in this case the required change was within a method part of the core (not in plugin and thus no plugin changes regarding this issue) and therefore a core update/restart was required. But with broken method in core, this can also have affect on plugin in meaning of *plugin broken*

[Jiaz]

Originally Posted by wppcproductions

Sorry to say If the YT bugs dont get solved with JD2.

Solved with latest update on sunday 13.20 o'clock.

[Jiaz]

@GNIREENIGNE
@jellytot
Please see https://board.jdownloader.org/showpo...postcount=5164
Thanks to @goldensun87 for taking time to explain this
You will have to wait (unknown how long it will take) till processing of the streams are finished but you will
have to readd the links.

[GNIREENIGNE]

Originally Posted by goldensun87

Maybe your video is/was a live stream

-Thanks. This was my first consideration. However, the stream is no longer live. In fact, it has been three days already since it was live.

That being said, I suppose that the video could still processing, since it is a 5-hour long video. I will keep trying and report back, either way.

Thank you for taking the time. I appreciate it.

Originally Posted by Jiaz

You will have to wait (unknown how long it will take) till processing of the streams are finished but you will
have to readd the links.

-Thank you, Jiaz. It is possible that the video is still processing. I will keep trying and report back after giving it more time.

Thank you. I appreciate your efforts here.

[Jiaz]

Originally Posted by GNIREENIGNE

-Thanks. This was my first consideration. However, the stream is no longer live. In fact, it has been three days already since it was live.That being said, I suppose that the video could still processing, since it is a 5-hour long video. I will keep trying and report back, either way.

I know of reports that this process might take several days and even might take longer for longer videos. I guess live stream conversion are not high priority because the video already exists in a form (stored on server) that can be played back normally.

[GNIREENIGNE]

Originally Posted by Jiaz

I know of reports that this process might take several days and even might take longer for longer videos.

-Okay. I will let you know what I experience with it and if anything changes.

Thanks, again.

[wppcproductions]

Thanks a millions Jiaz for fixing this problem...I rerun my YT files with the DASH turned on in the advance settings and all download speeds are back to normal..

Users got to remember they have to delete to old YT links and reload Link Grabber with new YT links of video from the channels they chose to download from if they want the DASH versions..

Thanks again Jiaz and the JD2 Dev Team for your dedication to keep JD2 up and running through a fast pace of changes in the world of computer environment.

BTW Did not have a packaging problem as as reported by other users.

[wppcproductions]

For live streams I usually wait until few hours later or until the next day after the stream is done. But as long the channel user want to share the stream for their subscribers to watch again or missed the live stream .Thats the bonus and the opportunity to download it for keepers.Depends how long the live stream video . The reason for the wait time is because the live stream has to go the process as it gets rendered at YT for it will get posted for replay.

For a 10 hour live stream that I wanted .I waited approx 12 hours until done rendering at YT to get posted on the users channel .And another 10 to 12 hours to download via JD2 at normal speed. It was will worth the wait..

[JDmurphy]

Originally Posted by Jiaz

The update was released sunday at 13.20 o'clock.

I just so happened to catch the notification for that one immediately, installed the update, and after restart initiated a new download of a 224,244 KB video which according to logs took 53 mins to finish, averaging exactly to the widely reported 70 Kbit/s throttled speed - and only after sending my post above (and heading to sleep bc it was already midnight) I found this helpful hint:

Originally Posted by TheRenegadist

If anyone updates and still gets slow speeds I had that happen but only for the last video I had downloading in my queue, once that finished the speeds were good.

While that was true for two of my downloads, which resumed seamlessly, not only those but also newly queued links like the abovementioned one were throttled ...

Originally Posted by Jiaz

But it's unpredictable when/if existing links in list will benefit from the update to have better speeds because only if cached links are expired/failed then JDownloader will reprocess them and be able to incorporate the fix.

... and this explains it!
Once the LinkGrabber grabs a link, it's cached - so apparently all the affected links were already grabbed just recently before updating, hence not reprocessed, hence didn't get the fix applied, and were therefore throttled even though I had not added them to the download queue yet.

Assuming this is correct, there's only one question left (that would possibly require explanation :>) which is:

I have prepared handling for auto refreshing links but this is not ready yet.

What's your thoughts on executing a refresh also when a RightClick>Other>Reset is initiated?
Because that turned out to be the only other obstacle: Even after resetting links, they were still throttled - so I guess a reset doesn't refresh them. Since resetting links clears a whole variety of issues, you could suppose this to be expected behavior.
Not that it matters much right now as youtube currently seems to chill with the throttles, but maybe this manual refresh is simple enough to amend before rolling out the auto refresh you mentioned, just to have something in the meantime.

Originally Posted by Jiaz

I just wanted to explain

Originally Posted by JDmurphy

to convey right away that I'm aware plugin fixes can be applied in the background so that JDownloader can directly make use of them while core updates do require a restart

... this? yet again?

Originally Posted by Jiaz

in case the issue/bugfix is within a plugin only, it can be fixed/updated(with the plugin only advantages in mind) and doesn't require/depend on any core changes. But in this case the required change was within a method part of the core (not in plugin and thus no plugin changes regarding this issue) and therefore a core update/restart was required.

Still looks like the same thing to me (just as the other two quotes compared above) but idk maybe that's just me

Originally Posted by JDmurphy

"Due to changes in the player.js library the JD youtube plugin wasn't working properly, and a core function had to be fixed to make the plugin work again while fixing the plugin itself wasn't required."

Originally Posted by Jiaz

But with broken method in core, this can also have affect on plugin in meaning of *plugin broken*

Sounds familiar
So I guess the quick&short answer is "no, there's no essential difference, you got that right straight away"

But since we're at it (again), both updates on Sunday 4th required a restart, but as noted in #5161 both still had the same build number #46668. I noticed the same on May 14th/15th with build #45992.
Given that only core updates (as I first mentioned in #5118 and since then got "confirmed" many many times) require a restart, that consequently means there are core updates that don't justify/receive a new build number?

[GNIREENIGNE]

Originally Posted by GNIREENIGNE

-Okay. I will let you know what I experience with it and if anything changes.

Thanks, again.

-Just for your information, after four days, the video is now available for complete download.

Thanks to everyone that has replied.

[rezad]

Originally Posted by pspzockerscene

@rezad
Filename for video files -->

*VIDEO_NAME* *quality*(*HEIGHT*p)*.EXT*

no.
I need a the info for max resolution not the downloaded resolution.
the one you suggested would put this in name 428p for 854x428 downloaded youtube link that has even 3840x1920 1920p.
what I need is for youtube download file to be named 854x428 1920p.

[Jiaz]

Originally Posted by GNIREENIGNE

-Just for your information, after four days, the video is now available for complete download.

Thanks for the feedback

Originally Posted by rezad

I need a the info for max resolution not the downloaded resolution.
what I need is for youtube download file to be named 854x428 1920p.

Use the following to return the itag best resolution

*BESTRESOLUTION*

or the following to return actual best video height

*HEIGHT_BEST*

(after next update)

[JDmurphy]

Regarding downloading whole channels/playlists with 100+ videos:

Originally Posted by zToRm777

Video Liste in Youtube öffnen, mit FoxScroller (Firefox-Add-On) automatisch runterscrollen lassen, mit Link Gopher alle Links extrahieren, Links kopieren, in JD einfügen.

Especially for larger channels or longer playlists I found another interim solution; there are online tools/sites providing the benefit of extracting and downloading the whole "Uploads" list in a few seconds in .csv or .json format, with some of those lists even limited to videos that are de facto accessible ("available.json"), excluding unlisted and private videos.

Either by copypasting the lists entirely while clipboard monitoring is active, or even better after filtering them for actual video urls (to avoid included channel/playlist/random other urls being grabbed and then being prompted by JDownloader if you wish to process those as well), you get a clean LinkGrabber folder with a link collection of all the videos up to hundreds if not thousands at a time ... I haven't tested the limits yet.

Another option - with deactivated clipboard monitoring - is to copy those lists, open the Add and Analyse Links dialog with the Add New Links button bottom left in the LinkGrabber tab, and paste them there. This has the advantage of getting a progress dialog that illustrates the process.

The scrolling down method is limited by youtube just stopping after a couple hundred videos and just not populating more videos to the browser tab at some point, so this alternative might also be the only chance to fully get a complete list of a larger channel's whole uploads.


edit: The site I'm using myself for this (and for other purposes like upload date/time extraction as well) on a daily basis was intentionally not named/linked, because that specific application is traffic/request capped and already runs into its limits now every once in a while. It should be fairly easy to find it or a similar one tho.

[Jiaz]

Originally Posted by JDmurphy

... and this explains it!
Once the LinkGrabber grabs a link, it's cached - so apparently all the affected links were already grabbed just recently before updating, hence not reprocessed, hence didn't get the fix applied, and were therefore throttled even though I had not added them to the download queue yet.
Assuming this is correct, there's only one question left (that would possibly require explanation :>) which is:
What's your thoughts on executing a refresh also when a RightClick>Other>Reset is initiated?

Already working on that

Originally Posted by JDmurphy

Even after resetting links, they were still throttled - so I guess a reset doesn't refresh them. Since resetting links clears a whole variety of issues, you could suppose this to be expected behavior.

Because there are link local caches AND session caches. Reset currently only clears link local cache, will have to update it to also refresh session cache

[JDmurphy]

Originally Posted by Jiaz

Reset currently only clears link local cache, will have to update it to also refresh session cache

Great news, thanks!

Originally Posted by JDmurphy

[...], that consequently means there are core updates that don't justify/receive a new build number?

If I'm correct, just a "yes" would hit the spot ... if I'm wrong, nevermind!

[Jiaz]

Originally Posted by JDmurphy

If I'm correct, just a "yes" would hit the spot ... if I'm wrong, nevermind!

"yes" but I'll try to explain it

consequently means there are core updates that don't justify/receive a new build number?

those *build numbers* are the actual revision of the source code used for the build. but regulary plugin only builds/updates only checkout/build plugins and thefore the core revision does not change. unfortunately there is (not yet) no plugin buld revision and therefore plugin-only builds/updates will have changed build date but unchanged revisions.