Josh.5

So this is a very simple breakdown of what unmanic currently does. I'm in no way an expert with ffmpeg, so I welcome anyone to come forward and tell me this is wrong and it's not working this way.... for each video stream: re-encode: bitrate: source resolution: source codec: hevc (can be configured in settings) encoder: libx265 (locked to codec at the moment) for each audio stream: (if audio channel has more than 2 channels (not stereo):) clone source audio channel (does not re-encode) copy source audio channel re-encode to stereo (with same title where possible. Eg. English -> English Stereo): bitrate: 128k codec: aac encoder: aac (if audio channel is stereo:) re-encode stereo audio channel: bitrate: 128k codec: aac encoder: aac for each subtitle stream: (if setting for stripping subtitle streams out of mux is set) do nothing (subtitles will not be cloned to destination) (else) clone source subtitle stream (does not re-encode)

Not at this point in time sorry. Sent from my ONE E1003 using Tapatalk

At the moment this docker is still beta. There are too many features missing. I'm afraid of it is added to the community application installer I may get inundated with feature requests. At the moment I'm tied up with work til possibly around April. I'm able to set aside small bursts of development effort to work on this app, but it is not easy to dedicate the time needed for the bigger features. Sorry for the inconvenience. Sent from my ONE E1003 using Tapatalk

This is on my todo list. Its a good idea. Sent from my ONE E1003 using Tapatalk

This is not hard coded. This is a request from an open browser. Check on your network what device is 192.168.0.12, it will have an open browser tab looking at the webUI dashboard. This will be polling every 5 seconds for an update for the workers. These logs are already on my todo list to move to their own file like I did with the main service logs and implement a log rotation of 7 days

That may be something.... I'll log it and look into it when I get time.

@trekkiedj @itimpi Yea you guys were right. I made a mistake with the config that cased it to try and export our logger to the settings file... oops. As you predicted this broke things like running a scan on start as the settings file was corrupted and everything reverted to defaults. There is an update building now. Once you have it just open the web UI to the settings tab and click the "Submit" button to save the settings (this will over write the buggered settings file). Make sure you also double check that all the settings are correct, they have likely reverted back to the defaults. I've added an update to my todo list (https://github.com/Josh5/unmanic/issues/21) that will add a layer of protection against this in the future. This will be easy enough to implement. Thanks for the report

I'll take a look this morning Sent from my ONE E1003 using Tapatalk

I've partially finished updating the logging. This may not cut down on log sizes yet, but now that I've done this first part I can implement a log rotation so logging is only kept for X amount of days.

Yea buddy. Kiwi here. Sent from my ONE E1003 using Tapatalk

Thanks for the gratitude. I'm glad that this tool is useful to others You can take a look at the commit log on github: https://github.com/Josh5/unmanic/commits/master Anything committed to the master branch will be automatically built and taged as "josh5/unmanic:latest". I have not yet setup any sort of release notes, but as a rule I do my best to ensure my commit messages on github explain the reason for the code change and what it is fixing (opposed to just saying what was changed as many people do).

Actually I got halfway through the CPU slamming and logging issues on Wednesday (it was a public holiday over here). There should be a build sitting on :latest that fixes the CPU slamming while idle. I have not been able to finish the other issue yet Sent from my ONE E1003 using Tapatalk

It's possible I severely underestimated the amount of data going into the logs with debugging turned off. Sorry about that. Sent from my ONE E1003 using Tapatalk

Make sure you have debugging turned off. Unless you have faults, there is no point. The application is just logging to docker logs at the moment and so there also is no log rotation. Later on I'll update the container to log to a file and include a daily log rotation. With debugging turned off your log should be about 10KB per file processed. With it enabled this could be in the MBs ad it logs progress ever second of every file. Sent from my ONE E1003 using Tapatalk

I'll figure something out for you Sent from my ONE E1003 using Tapatalk

Yea. The logs are excessive when debugging is enabled. I'd suggest keeping it off unless you are encountering issues. If you really wish to keep debugging enabled you can also truncate your docker logs. Sent from my ONE E1003 using Tapatalk

Yea. Same. I have a bunch of series that I keep for rewatching etc. Mist of the episodes were around 1gb each. Now they are closer to 300mb each. Sent from my ONE E1003 using Tapatalk

Yea. I'm seeing it also. I have an idea of what it is. I'll let you know when I have a fix. Sorry about the delay. I'm pretty busy at work this week. Sent from my ONE E1003 using Tapatalk

No. You will be able to. The spawned ffmpeg process will use all available CPU cores. There is a difference between a "process" and a "processor". The main python application runs multiple threads but on a single process (usually this means the application will only use one core at a time while idle). When it starts a ffmpeg job as a separate "subprocess", ffmpeg is able to also create a number of subprocesses itself. The ffmpeg subprocesses are optimised by default to take advantage on all CPU cores (processors) available. So... If you run only one worker with one ffmpeg job, it will still convert using all CPU cores available. The reason for having multiple workers is because you will likely be bottlenecked by other things (such as HDD RW). Therefore running 2-3 workers/jobs at a time should get you the fastest conversion of your library. If you have a CPU with 16 cores, you probably will not be able to saturate them with 2 jobs. You will need to increase the number of workers. However, a 4 core CPU will likely only handle 1-2 jobs at a time. Any more any you may start to slow down your library conversion. All this needs testing BTW. To see what works faster. Sent from my ONE E1003 using Tapatalk

To answer your question in a more technical way. The core application of unmanic is a single process application. It can only take advantage of a single processor at a time. There was a bug that I fix las week that caused it to slam the CPU use when the main process was idle. Can you confirm that you are running the latest version of the docker image as it should not be doing this any longer? To be clear, the main unmanic service runs on a single process (as is the nature of any python application), but each worker spawns a separate process that can take advantage of multiple processors for the encoding task. Sent from my ONE E1003 using Tapatalk

@BomB191 @zAdok @trekkiedj I've pushed an update to the docker container again tonight. There was an issue with the new method for parsing progress information. It was piping it to a temp file to read. This was somehow falling over as soon as you give it a file with a decent size but at random times (anywhere from 30MB to 60MB). I missed this as all my test files are 10MB or less. I've refactored this code and added support for elapsed time, time position, frame, fps, speed, bitrate and file size along with percent. While this information is now available, I have yet to implement it in the worker elements of the WebUI. But I'll see if I can throw that together this week. If you care to look at what info is there, you can open http://{UNMANIC_IP}:{UNMANIC_PORT}/?ajax=workersInfo while you are converting to see all your jobs information in json format. PS. This is now version 0.0.1-beta3 (displayed in the bottom left of the WebUI)

I'm taking a look now Edit: This may require a bit more investigation. I'm leaving some tests running while I head to bed. I'll let you know what I find in the morning.

What are the characters of this file: Storage Wars - S12E09 - Let's Give \udce2\udc80\udc98Em Something to Tonka About - WEBDL-720p - h264 AAC.mkv I have a funny feeling that this is not longer a problem and that somehow the file's names managed to make it through the conversion process and written to this history in this messed up state. The changes made on the last update should prevent this from happening again. So if it does happen again please report it to me. I will see if I can come up with a tidy way to gracefully handle this error in the webUI so it does not error out quite so hard...

ta. Give me a few mins to take a look...

The log that he is showing is from the webUI. It is reading some non unicode character from his history log file and falling over. If I can see what that character is I may be able to figure out why it cannot convert it to a string.