StaxRip

[Schattenspieler]

You should try this thread instead, if using Staxrip 2.x: StaxRip 2.0 Support Thread

[stax76]

Thread was reactivated because an up to date first post is important. Thread title was changed to simply StaxRip.

I've uploaded a new build, many changes are internal like generating documentation files or improving legacy code, Windows Terminal users might still like it though. This terminal thing has become a passion...

My markdown to BB conversion script isn't working correctly and posting markdown won't work well because of URLs so I just post the link to the change log, maybe fix the script later.


2.1.0.6 Beta


Changelog

https://github.com/staxrip/staxrip/b...r/Changelog.md


Download

https://staxrip.readthedocs.io/introduction.html#beta

[JKyle]

Originally Posted by stax76

I've uploaded a new build, many changes are internal like generating documentation files or improving legacy code, Windows Terminal users might still like it though. This terminal thing has become a passion...

2.1.0.6 Beta

Changelog

https://github.com/staxrip/staxrip/b...r/Changelog.md

Download

https://staxrip.readthedocs.io/introduction.html#beta

Tools > Advanced > Command Prompt or PowerShell seems to open Windows Terminal correctly, but the window title is set to the default Profile, which is PowerShell Core in my case.
And other Profile attributes like background, icon, colorScheme, etc. are ignored.
Is this a bug in Windows Terminal?
My Windows Terminal is the most recent one.

[stax76]

I've not installed the latest PowerShell version 7.1 but still use the one that is part of Windows 10, version 5.1. Here the title is just PowerShell like my Windows Terminal default profile.

What staxrip does when you invoke this features is starting a process using:

file: wt.exe
args: powershell.exe -nologo

1. The process is created with shell execute disabled so environment variables can be passed in.

2. The working dir is set to desktop.

3. All console tools are added to the path env var.

4. All macros are added as env vars.

What could be done is to allow defining custom args in the settings and a custom working dir or improving the defaults. I'll think about it and bookmark the post.


Btw. I changed my mind on always using or even trying the newest platforms, in fact I will soon likely back port MediaInfo.NET to .NET 4.8 so users don't have to install a big runtime only because of one small app. mpv influences me, they are doing all this in pure C not using all the fancy new C++ 20 features so old tools cannot be so bad, of course there are exceptions like cmd, I hate this thing.

[stax76]

@JKyle

The next build uses the command ExecuteCommandLine to show the terminal, ExecuteCommandLine was extended to have a Working Directory parameter.

The defaults are:

Name: Windows Terminal
Command Line: wt.exe
Working Directory: Desktop

It can be customized in the menu editor, unfortunately I can't just reset the menu because of it. Internally the old commands still exist for backward compatibility with added description that the command is obsolete since 2020.

[SiliconKid]

Hi

I'm new to StaxRip and I'm using it to re-encode UHD content that is very high bitrate (60+ Mbps) with very large files (50 to 80GB MKVs).

It's working very well on the whole and I'm impressed but I have a question regarding the workflow involved and in particular, the background process that runs after demuxing and indexing are complete.

I've noticed that sometimes, but not every time, after the demux and indexing are done, the GUI disappears completely and then a background process continues to run for an extended period time using around 28% CPU, no disk and no network.

Image attached.

Initially I thought StaxRip had crashed or hung when that happened, but after the 3rd time it happened I decided to just leave it alone and wait and see what happens, and sure enough, when I came back to check on it quite some time later, the GUI had re-appeared and the job was ready for execution.

The question is:

What exactly is happening in that background process that is taking so long, given that the demux and indexing are already complete and it's only using CPU?

[stax76]

I don't remember it precisely but it was investigated and revealed, I think the outcome was that it was auto crop or slow source filter loading and for the slow source filter loading the reason was the nature of the source file, in particularly how many streams the source file has, if it has 50 subtitle streams you will see this behavior. Workaround is ripping exactly only the streams you need. I keep the file that a user has uploaded for me to reproduce, it has 50 subtitle streams. I think all source filters showed the behavior, maybe the problem is how MKV files are structured, I'm not an expert on this topic. I'll add a Known Issues page in docs.

[videoh]

That's a pretty feeble answer. You wrote the application. What is it doing during this time?

[stax76]

Originally Posted by videoh

That's a pretty feeble answer. You wrote the application. What is it doing during this time?

Probably it's waiting for a function to return, a function of the avisynth/vapoursynth API, I remember a issue with your source filter like very slow indexing mkv, don't remember it exactly, sorry that I can't remember everything. I kept this 50 GB, 50 subtitles file just in case, theoretically I could upload it, my connection is not bad for German standards. I don't want to blame the source filters, staxrip surely could do better like showing a message telling, this might take a while for this and this reason, but it's difficult, so I just accept that it's not perfect, the GUI just disappears in that time, it's a flaw in staxrip I admit.

[videoh]

Originally Posted by stax76

Probably...

Hit break in the debugger and see what's running.

I remember a issue with your source filter like very slow indexing mkv, don't remember it exactly, sorry that I can't remember everything.

You can't remember but you'll spread FUD anyway. Shameful. And anyway, the OP said this occurs after indexing is complete, not to mention that the source filter doesn't do indexing. Groping in the dark much?

I don't want to blame the source filters

After you just did.

it's a flaw in staxrip I admit.

[stax76]

I was afraid you react that way, we had this many times before, let's just say these weren't my best posts and I apologize.

[Patman]

Originally Posted by videoh

Hit break in the debugger and see what's running. As I said, it's your application.

You can't remember but you'll spread FUD anyway. Shameful. And anyway, the OP said this occurs after indexing is complete, not to mention that the source filter doesn't do indexing. Groping in the dark much?

After you just did.

Then why spread FUD on my source filter?

I can help you with debugging this, if you are actually care about it. Sounds like you don't.

hi videoh, i'm a little scared that you react that way . As far as I know, this problem has been extensively investigated. Here is the link, which is probably the cause. The whole discussion on the subject started here.

[videoh]

Originally Posted by Patman

hi videoh, i'm a little scared that you react that way . As far as I know, this problem has been extensively investigated. Here is the link, which is probably the cause. The whole discussion on the subject started here.

Didn't see any conclusive analysis or solution at your link. What were you referring to?

Simple question: what is staxrip doing during this delay? According to OP it happens after the file was opened and indexing is completed but before the job is started.

EDIT: I see that stax76 said staxrip is querying Avisynth for some information. Can you give more details about how you are doing that? Have you verified that the delay is in the query and not in whatever staxrip tries to do with the info?

Don't be scared; just trying to help. A link to the file would help a lot.

[Patman]

I also did not refer to a "final analysis" or a "solution", I only remarked that the matter had already been investigated. The subtitles were an indication. What exactly causes the delay has to be investigated, I agree with you. And I think the offer to help debugging is gladly accepted. In the future, UHD material will probably be used as a source more often than anything else.

[stax76]

It's probably waiting for a native function to return, possibly here:

https://github.com/staxrip/staxrip/b...Server.cpp#L75

I don't have great interest in this particular topic, I try to improve the staxrip docs and since this week I try to switch projects more frequently like daily, came across a mpv issue tonight. mpv(.net), powershell and terminal are currently my main interests.

[stax76]

It's a big file, according to some speed meter site and calculator it would take 5-6 hours and I don't know where to upload it.

I'll try that file tomorrow with DGDecNV and tell you about the details how it went.

[stax76]

I could not reproduce it now with any of the three source filters. Maybe it's fixed meanwhile or happens only randomly or only on certain hardware.

The auto crop routine causes it but it's only ten seconds on my test, it seeks ten frames by default, with HDD instead of SSD I guess it takes longer. The reason is it's a internal routine instead of a console tool like most other tools that need some time to process. I should probably think about if there might be a simple enough solution for it.

I had mentioned possible slow indexing, numbers are 7 minutes dgindexnv and 2 minutes lsmash and ffms2.

There was however a bug introduced 2 builds before causing a stack overflow triggered by dgdecnv usage.

2.1.0.7 Beta
============

new
---

- a new documentation page [Commands](https://staxrip.readthedocs.io/commands.html) was created.
- the built-in MediaInfo GUI was replaced with MediaInfo.NET which was ported to .NET Framework 4.8.
- the MediaInfo folder view powered by Get-MediaInfo.ps1 v3.0 is shown
  without starting a terminal and it has few bugs fixed.
- the issue templates on the [github issue tracker](https://github.com/staxrip/staxrip/issues/new/choose) were improved.
- `Main Menu > Tools > Advanced > Command Prompt` can be configured in
  the menu editor because it's based on the ExecuteCommandLine command.
  Only people who reset or manually config the main menu will see the change.
- the ExecuteCommandLine command has a new Working Directory parameter.


fix
---

- issue causing audio to be silently ignored instead of muxed
- since v2.1.0.5 DGDecNV usage triggered stack overflow causing staxrip to die silently

https://www.dropbox.com/sh/4ctl2y928...dd3yqcAHa?dl=0

https://1drv.ms/u/s!ArwKS_ZUR01g0kH4...3GaKe?e=qbOfGS


That's the file (info from MediaInfo.NET):


G: Matroska, 47.3 GiB, 2 h 10 min, 51.8 Mb/s

V: HEVC, Main 10@L5.1@High, 3840x2160, 23.976 FPS, 44.1 Mb/s

A: English, MLP FBA, 4 826 kb/s, 8ch, 48.0 kHz, Default
A: English, AC-3, 640 kb/s, 6ch, 48.0 kHz
A: English, AC-3, 192 kb/s, 2ch, 48.0 kHz

T: English, PGS
T: English, PGS
T: Arabic, PGS
T: Bulgarian, PGS
T: Chinese, PGS
T: Chinese, PGS
T: Czech, PGS
T: Danish, PGS
T: Dutch, PGS
T: Estonian, PGS
T: Finnish, PGS
T: French, PGS
T: French, PGS
T: Greek, PGS
T: Hungarian, PGS
T: Indonesian, PGS
T: Icelandic, PGS
T: Italian, PGS
T: Japanese, PGS
T: Korean, PGS
T: Latvian, PGS
T: Lithuanian, PGS
T: Malay, PGS
T: Norwegian, PGS
T: Polish, PGS
T: Portuguese, PGS
T: Portuguese, PGS
T: Romanian, PGS
T: Russian, PGS
T: Slovak, PGS
T: Spanish, PGS
T: Spanish, PGS
T: Swedish, PGS
T: Thai, PGS
T: Turkish, PGS
T: Ukrainian, PGS
T: English, PGS
T: Danish, PGS
T: Dutch, PGS
T: Finnish, PGS
T: French, PGS
T: French, PGS
T: Italian, PGS
T: Norwegian, PGS
T: Portuguese, PGS
T: Russian, PGS
T: Spanish, PGS
T: Spanish, PGS
T: Swedish, PGS

M: Menu

[SiliconKid]

Originally Posted by stax76

I don't remember it precisely but it was investigated and revealed, I think the outcome was that it was auto crop or slow source filter loading and for the slow source filter loading the reason was the nature of the source file, in particularly how many streams the source file has, if it has 50 subtitle streams you will see this behavior. Workaround is ripping exactly only the streams you need. I keep the file that a user has uploaded for me to reproduce, it has 50 subtitle streams. I think all source filters showed the behavior, maybe the problem is how MKV files are structured, I'm not an expert on this topic. I'll add a Known Issues page in docs.

Quick update on this.

I've just installed BETA 2.1.0.7 to see if that makes any difference.

I was running 2.0.8.0 before.

I'm still seeing the same delay with CPU use only after indexing completes, using AviSynth. Even if I use a 1 minute 3840x2160 sample clip there is a delay after indexing with no GUI visible.

I've narrowed it down to the Auto Crop filter. That definitely seems to be what's causing the delay in my case. And if it's delaying this much for a 1 minute clip, I can understand how the delay extrapolates to a much longer time period for a UHD video with a 1.5 to 3 hour runtime.

I've just tried using VapourSynth too, but 2.1.0.7 made me install a new version of VapourSynth and now it's refusing to work and throwing an error which I haven't been able to resolve yet. It was working with 2.0.8.0.

Anyway, it does seem to be the Auto Crop.

[stax76]

@SiliconKid

Thanks for the test, this year some longstanding issues like the slow preview and crop could be resolved, I hope this can be resolved soon too, and there will also be a long overdue tool cleanup.

[Patman]

@SiliconKid

I had the same issue with Vapoursynth. In my case, a clean install of Python and Vapoursynth helped. Uninstall the old versions, then install Python and choose customized install (have a look that you install these app for all users). Install Vapoursynth with admin rights and test again.