Without any logs or other details Im going to assume these are huge files (at 6 hours long) and mp4.
Settings > Advanced > Mux. Turn off fast start for faster muxing.
Thank you!
I wonder if the new version (7.0.19) turned it On as default, as this seems to be a very occasional problem over the years that I've (happily) used Jaksta... I seem to remember another default being changed but can't remember what that was - but it will have been something that slowed me down big time
--- Import ---
Author: Patricia
Created At: 2020-07-29T15:15:54+08:00
Updated At: 2020-07-29T15:15:54+08:00
Views: 88
Votes: 0
--- Import ---
Hey P.
Has been "on" since 7.0.10.0, which was the last "official" release. The reason it is on by default is that playback in alot of instances does not work to well unless the "index" is at the front of the mp4.
"Muxing" (combining audio and video streams that are delivered and captured separately) can be very time consuming depending on the size of the video and audio files captures and the video and audio codecs that are being combined. It also depends on the speed of your computer etc.
Anyway switching this setting to off stops the second pass to move the index to the start of the file. On 6 hour captures this will definitely cut down on the amount of processing time.
I made the change you suggested and restarted Jaksta (at which time the extraction engine was updated).
Just now I manually stopped a YouTube download @ 5h23m and 5 minutes later it was still "cancelling". I had to do other things so didn't see when it transitioned to "tagging" or when it completed, but it could well have been at least 8 minutes.
If only Jaksta would re-pick-up a stream as soon as it stops it.
(BTW, unrelated to current problem, but how quick and easy .flv streams are - and they're soon to be no more when Flash is withdrawn.)
PS - I have a relatively fast laptop - Dell XPS 15 9560 with 32GB RAM. Can't remember the CPU off-hand.
Yep as I said muxing streams is avery time consuming/resource intense process depending on the codecs etc that are being combined and if any conversion needs to occur. Especially when you are talking about such huge captures.
The current problem with my "huge" captures is a resurgence of one I reported in Nov 2017:
It fixed itself back then (the fix I reported in that thread that I'd done myself was only for flv files, where the "automatically fix RTMP" had been switched on in a new version and I switched it off),
I never found out what setting had affected the mp4 YouTube live stream downloads, it is they which are being cancelled/muxed "ad infinitum" now, and I'm missing +/- 15 minutes between the end of a download and the start of a new one... in which time there can be (bird) world-shattering events !!!
Dang! I presume I just have to wait until Jaksta's internals revert to friendly settings in a new version.
The problem would not be so severe if Jaksta would re-pick-up a stream without waiting for the completed one to be finalised. Is this impossible?
Ive explained this several times:
You are capturing for 6 hours, separate audio and video streams. They will be gigs in size.
Your flv post is exactly the same - it was muxing to FLV and re-indexing the file to make sure it is playable. Now the streams have changed and it is muxing to MP4, separate audio and video streams at with different codecs etc that need to be sorted so they can consist in the same MP4 container .
Muxing can take a long time, when audio and video have to be combined and converted. We distribute and use ffmpeg to do this which is the "gold standard" converting software. How fast that happens depends on the size of the files and the codec etc they are in and the speed of your computer.
Are you using the JMR Monitor function? If so then set the split settings that are on every monitors tab so that the capture can finish in a time that is suitable to you. I'm not sure how a capture can finish before it is finished.
If you arnt then please explain what you mean by the bold text of your post.
For years I used Auto but changed to Monitor when I eventually realised how it worked. Also, developments at YouTube played a part.
FLV streams
I download from only one site in FLV, and that is starrranch.org/blog. That is because it is the only site that still uses Flash. The downloads finalise instantly, and sometimes I've forgotten to stop them at ~20 hours long but they're ready instantly. I do not choose to use FLV, it chooses itself.
MP4 streams
That's how YouTube streams come down, I don't use any setting to specify a format. YouTube streams on Monitor automatically stop themselves at 6 hours - I have set the Check Interval @ 15 seconds so as not to miss activity between the 6-hour sessions, but the Monitor does not pick up the stream until Jaksta has finished with the stopped stream, which, these days, can easily take 15 minutes. That can be a disaster (in the world we're talking about!).
I attach a snap from a different YouTube stream (quite low res)
showing the delay between the end of one session and the start of the
next - not all the cams have an embedded timeline like this one does.
Therefore, in the bold sentence, I'm asking that the Monitor will re-pick-up a stream after it has been stopped without waiting for the stopped stream to be finalised, by which I mean "Complete".
A short while ago I manually stopped a YouTube stream @ 4h37m and watched and timed it. It was Cancelling for 14 minutes - it then changed to Tagging/Complete in very quick succession. It did not Mux at all. The completed file is as it should be.
Almost at the same time I noticed another YouTube stream stop itself and it was reporting "muxing ... %" - why some have to mux and some not is another mystery... Well, the one I manually stopped that spent ages cancelling was 720p and the muxing one was 1080p, if that makes any difference. Both had video with sound.
There is no time "suitable" for split times to be set. I need to monitor 24/7 and that used to be achievable with minimal gaps between the 6-hour "sessions".
I wondered if my disk could be too full but it has 340GB free of 730GB (it's the data partition of a 1TB SSD), I've been using the same hardware for over 2 years and was using less powerful hardware previously with no problems - except when I reported "muxing ad infinitum" in 2017.
I hope this clarifies my tasks and problem.
>>> I download from only one site in FLV, and that is starrranch.org/blog. That is because it is the only site that still uses Flash. The downloads finalise instantly, and sometimes I've forgotten to stop them at ~20 hours long but they're ready instantly. I do not choose to use FLV, it chooses itself.
RTMP or direct FLV streams normally stream audio and video together and so dont need to be combined and their video and audio codecs will be compatible so no muxing is required. You can switch on through the settings to automatically fix live streams and add a duration. This will result in Muxing as a status in the UI. Again this can take sometime depending on the size of the captured file, but does not involved codec conversion.
>>> That's how YouTube streams come down, I don't use any setting to specify a format. YouTube streams on Monitor automatically stop themselves at 6 hours - I have set the Check Interval @ 15 seconds so as not to miss activity between the 6-hour sessions, but the Monitor does not pick up the stream until Jaksta has finished with the stopped stream, which, these days, can easily take 15 minutes. That can be a disaster (in the world we're talking about!).
Youtube stops the stream after 6 hours, not JMR. JMR is intended for personal use for a bit of fun and is not designed or intended to be used for commercial or mission critical tasks.
As I have said a 6 hour recording will be quite large and muxing can take a while. The length of time you are reporting is not unheard of depending on the codecs being muxed together and their size.
>>> A short while ago I manually stopped a YouTube stream @ 4h37m and watched and timed it. It was Cancelling for 14 minutes - it then changed to Tagging/Complete in very quick succession. It did not Mux at all. The completed file is as it should be.
If you cancel - it just displays cancelling in the UI but it will be muxing if the audio and video streams require muxing so that a usable file is provided. You can see this in the Progress Log.
>>> Almost at the same time I noticed another YouTube stream stop itself and it was reporting "muxing ... %" - why some have to mux and some not is another mystery... Well, the one I manually stopped that spent ages cancelling was 720p and the muxing one was 1080p, if that makes any difference. Both had video with sound.
If a stream has finished then it displays muxing in the UI.
>>> Therefore, in the bold sentence, I'm asking that the Monitor will re-pick-up a stream after it has been stopped without waiting for the stopped stream to be finalised, by which I mean "Complete".
I can have a look at that for you. Not sure if it will be doable or when it might be implemented if it is.
>>> There is no time "suitable" for split times to be set. I need to monitor 24/7 and that used to be achievable with minimal gaps between the 6-hour "sessions".
JMR is intended for personal use for a bit of fun and is not designed or intended to be used for commercial or mission critical tasks. If you split every hour or less you will be muxing much less data and therefore it will take much less time and any perceived breaks will most likely be smaller.
>>> I wondered if my disk could be too full but it has 340GB free of 730GB (it's the data partition of a 1TB SSD), I've been using the same hardware for over 2 years and was using less powerful hardware previously with no problems - except when I reported "muxing ad infinitum" in 2017.
Muxing is CPU intensive for the most part.
There is no commercial element whatsoever to what I do, I just need to be reliable - for example, if I say something did not happen then it must not have happened.
If you could possibly achieve the immediate re-pick-up of a stopped stream, that would be wonderful,
I appreciate your time.
I am looking for something similar.
It doesnt look like JMR even checks to see if there is a stream active until it has finished muxing.
This is behaviour I would like to be different - I dont care if there is a stream muxing currently, I would like the recording to start immediately when it can.
Failing that, is there any way to make the muxing faster? Checking my CPU usage it is only around 8% with no cores being maxed out. Are there ffmpeg parameters we can tweak to have it run multithreaded?
Muxing is an integral part of the download process at the moment.
Ive mentioned this above but for possibly quicker muxing,
1. Configure the monitored streams to split the stream so they are smaller and muxing will then be quicker.
2. Some users have said that later versions of ffmepg are quicker. You can download windows exe's by following the links here https://ffmpeg.org/download.html. Once downloaded, backup the existing ffmpeg.exe in the JMR install location and replace with the downloaded version.
I'm not arguing with the fact that muxing is required.
What I am saying, is that whilst muxing is going on, it shouldnt effectively shutdown the stream.
JMR can already download streams whilst simultaneously muxing another completed one, why does it need to wait for muxing to complete on a stream before resuming to download that same stream again?
I will try a newer version of ffmpeg though - thank you.
Support Migration
It's taking a very long time - several minutes - over "cancelling/muxing/tagging" etc - and of course a new download of the same stream does not start until completion, so I'm missing events on the cam.
This particularly applies to YouTube live streams, which I download 24/7, they come down in 6-hour files, each of which has to stop and complete before the download can resume.
Is there any way that Jaksta could resume a stream as soon as it reaches its limit, rather than wait for completion of the stopped download?
--- Import ---
Author: Patricia
Created At: 2020-07-29T15:15:54+08:00
Updated At: 2020-07-29T15:15:54+08:00
Views: 88
Votes: 0
--- Import ---