TUI becomes unresonsive during large move operations

[Soundtoxin]

I seem to get a timeout to the transmission daemon when moving some files. stig becomes unresponsive, then displays that message, then it's several minutes before the connection is restored and I can do stuff again. During this time I can check in a file manager and see file sizes are changing, showing the move is still going through, and then eventually it restores the connection on its own. I'm not sure if the problem is stig or transmission here...

I thought at first I was pushing it a little too hard moving maybe 50-100GB of stuff at once to another drive on the same machine, but now I just had the exact same issue moving around 10GB of stuff. This is annoying and doesn't seem normal to me. If it's really going to hang with every move, I'd rather be able to queue a move and then keep doing things so that I can move a few things around without interruptions.

[rndusr]

AFAIK, Transmission doesn't respond to requests while it is moving files. stig could work around that by having the RPC communication in a separate thread, but it would still not be able to connect to the daemon.

Can you move files in a separate stig process and report how that works? (e.g. "stig mv ")

Does the first process still work normally or do you get timeouts?

Does the first process become unresponsive?

[Soundtoxin]

How do I list out the torrents to move? I tried space-separated torrent IDs and that didn't seem to be right. The examples on the help page don't make it clear. I'm probably supposed to be familiar with filters also, but I barely understand them except in the simplest of cases.

soundtoxin@masaki:~/ > stig mv id=153 id=518 id=54 '/newfilepath'
move: Unrecognized arguments: id=54 /newfilepath
soundtoxin@masaki:~/ > stig mv id=153,id=518,id=54 '/newfilepath'
move: Invalid value for filter 'id': '153,id=518,id=54'
soundtoxin@masaki:~/ > stig mv id=153,518,54 '/newfilepath'
move: Invalid value for filter 'id': '153,518,54'

[rndusr]

Filter operators are mentioned at the end of "stig help filtersmanual". I guess this could be more prominent.

Filtering multiple torrents by ID is awkward. You need to combine filters with the OR operator:

stig ls 'id=153 | id=518 | id=54'

Usually you would filter torrents somehow else, e.g. all torrents with "foo" in their name that have a directory called "somewhere" in their list of parent directories:

stig ls 'foo & path~/somwhere/'

Can you explain what you don't understand about filters? Maybe I can improve the docs.

[Soundtoxin]

Can you explain what you don't understand about filters? Maybe I can improve the docs.

Mainly it's just a lot to take in. More examples could help, so I can skim and find what I'm looking for. I get the feeling I won't use most filters pretty much ever.

I wasn't sure if I'd be able to easily filter by names, so I went with IDs. Names should be easier to work with, I guess.

I figured out how to move by partial name after your examples just now, although in my case the path thing wasn't that helpful because I save things to very specific paths. e.g. shows in /storage/tv/tvshowname. I tried just putting /storage as path and also tried /storage* and it didn't work, just said no matches. but filtering by name was enough. Is there a way to look for matches in just part of the path?

As for the test, I started the stig mv command, then went back to my open tui and started moving around, trying to view torrent info or torrent files. It wouldn't load any of the info for me, but the tui itself didn't hang. It took maybe 30 seconds or so before I got an error there.

05:43:59 Unclosed client session
         client_session: <aiohttp.client.ClientSession object at 0x7f32e04f9d90>
05:44:29 details: Timeout after 10s: http://HOST:PORT/transmission/rpc
05:47:01 log: Missing at least one argument

Back in the shell where I ran the mv command, I see this:

soundtoxin@masaki:~/ > stigm mv 'show name' '/newfilepath'
move: Found 3 ~'show name' torrents
move: Moving to /newfilepath Season 3
move: Moving to /newfilepath Season 1
move: Moving to /newfilepath Season 2
move: Timeout after 10s: http://HOST:PORT/transmission/rpc

The move went through just fine it looks like, so basically the behavior was pretty much the same. Both got timeouts, but the error in the TUI side was different than before somewhat. (the missing argument thing might've been when I was trying to view torrent info in the tui during the timeout or something, not sure)

[rndusr]

I tried just putting /storage as path and also tried /storage* and it didn't work, just said no matches. but filtering by name was enough. Is there a way to look for matches in just part of the path?

That's what my example should do. It's also in "stig help filtersmanual": "~" matches if the item's value contains the literal string VALUE.

More examples:

"stig ls 'path~/foo/'" matches torrents with a directory called "foo" in their path.

"stig ls 'path~/foo'" matches torrents with a directory name that begins with "foo" in their path.

"stig ls 'path~foo/'" matches torrents with a directory name that ends with "foo" in their path.

Your findings seem to confirm my expectations. Transmission doesn't respond to RPC requests during the move operation. Staying responsive is pretty much all stig can do. It's weird that stig hangs when you execute the move command in the TUI.

The "Unclosed client session" error is something I've also seen. Unfortunately, I don't know how to get rid of it.

[Soundtoxin]

"~" matches if the item's value contains the literal string VALUE.

Ah! I missed the ~ at first. That does work. Cool. I'll have to read the filtersmanual page all the way through at some point.

It's weird that stig hangs when you execute the move command in the TUI.

I don't actually remember for sure what this was like earlier, I just did another move test and it seems similar to when I did the separate CLI move and then flipped back to the TUI. I can move around my torrent list, but viewing any info/file list screens doesn't show the actual stuff, and after a bit it times out. It might be that it doesn't hang after all. I'm not sure if I misspoke earlier or what, but this can probably be closed.

[rndusr]

I'll have to read the filtersmanual page all the way through at some point.

Please do. I took the time to write it so I don't have to answer simple questions like these. I know it's more convenient to ask than investigate on your own, but you may not learn as much and you are wasting other people's time.

It might be that it doesn't hang after all.

OK, thanks for testing again.

[Soundtoxin]

I do look at the help pages, but really I don't find them very accessible. I haven't got more specific critiques, really, but compared to the usual man pages they feel harder to deal with and read through. I did specifically say "all the way through", you wouldn't typically read an entire man page when you're looking for one option.

Any answer you give me here can also help someone else in the future, it's not so different from working on the help pages. Asking and investigating on my own generally happen in parallel. I'm not sure if you have the wrong idea or not, but I felt the need to clarify some things here.

[rndusr]

I did specifically say "all the way through", you wouldn't typically read an entire man page when you're looking for one option.

"stig help filtersmanual" prints 64 lines, including examples and blank lines. I absolutely would read that all the way through that before asking a question that is answered on line 10.