Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lowjoel]

I am curious if the newest Ogg encoder can be used with MC16 for media transcoding for portable devices.

I see that oggenc2.exe is being called from the MC AppData folder under Plugins, and in theory, I would imagine that it would be possible to replace that with a similar oggenc2, even if it is linked to a different libvorbis (or aoTuV or whichever encoder one prefers.) I think this was mentioned for an earlier version here.

Anyway, so I've tried to use all builds on the Rarewares page (x64, P4, generic) and both libvorbis and aoTuV. The result is that syncing generally works; but after a while, MC hangs in a deadlock (GUI etc locks up, nothing short of an end process will kill it.) The file which is being encoded at the point in time changes with each attempt and as such the file would not seem to be the issue at hand. Restoring the stock binary will allow the sync to complete.

I'm running Windows 7 x64. Any advice will be much appreciated. Thanks in advance!

[bob]

I am curious if the newest Ogg encoder can be used with MC16 for media transcoding for portable devices.

I see that oggenc2.exe is being called from the MC AppData folder under Plugins, and in theory, I would imagine that it would be possible to replace that with a similar oggenc2, even if it is linked to a different libvorbis (or aoTuV or whichever encoder one prefers.) I think this was mentioned for an earlier version here.

Anyway, so I've tried to use all builds on the Rarewares page (x64, P4, generic) and both libvorbis and aoTuV. The result is that syncing generally works; but after a while, MC hangs in a deadlock (GUI etc locks up, nothing short of an end process will kill it.) The file which is being encoded at the point in time changes with each attempt and as such the file would not seem to be the issue at hand. Restoring the stock binary will allow the sync to complete.

I'm running Windows 7 x64. Any advice will be much appreciated. Thanks in advance!

Just to satisfy my curiosity, reduce the number of simultaneous encodes to 1 (convert format->options) and try again.

[lowjoel]

Yeah, it doesn't work with either 1 or 2 parallel conversions, the result's the same (didn't wanna try 3). Oh, if I may add, when everything locks up, Media Center uses 100% of 1 core and no oggenc2.exe processes will be active.

[lowjoel]

bump -- anyone please?

[bob]

We tested it using a single large file. The tag writing is VERY slow. MC has to rewrite the whole file on conversion because the tag is at the beginning. On my machine, it seemed to freeze but when I looked it was building a file with the tag info. Waiting several minutes, it finished. It shouldn't be locking the database during that time and that will be corrected. We are looking into why the file rewrite is slow also.

[lowjoel]

Thanks for trying to debug this, much appreciated.

Hmm, it is strange. On my end, I did the sync overnight and out of 2000ish files to be synced, it stopped at around 10% of the total, and ran overnight without resolving itself. On the next morning, JRiver was still frozen and CPU usage for the process remains stuck at 100% of one CPU core.

Would it matter that in my case the %APPDATA% folder is a network share?

[bob]

Thanks for trying to debug this, much appreciated.

Hmm, it is strange. On my end, I did the sync overnight and out of 2000ish files to be synced, it stopped at around 10% of the total, and ran overnight without resolving itself. On the next morning, JRiver was still frozen and CPU usage for the process remains stuck at 100% of one CPU core.

You might try the 126 build. It fixed one ogg problem. The next build >=127 will change the locking that MAY affect your problem. Also, the ogg and vorbis libraries are updated to the current version.

Would it matter that in my case the %APPDATA% folder is a network share?

I don't think so in this case since the encoded file is written to your portable (real or virtual) and stacked if your options are set to do that. The oggenc2.exe file being in APPDATA shouldn't matter unless the share becomes temporarily unavailable, even then I don't think it would hang.

[lowjoel]

Thanks; let me try to see if >=.127 solves this and I'll post back here.

In passing, is it a known problem that if MC is terminated in the middle of a sync that the portable device will sync from scratch (= delete every file, or files are all reported as "delete on sync", then proceeds to sync every file back to the device) from then on? It seems like during this period of time when I was using the updated encoders my handheld library was inconsistent and that I had to delete all the music on my device and the JRInfo and JRState XML files in the root of my device. Should I open a separate thread for this?

[bob]

Thanks; let me try to see if >=.127 solves this and I'll post back here.

There's a bug in the rarewares ogg encoders in that they independently open the temporary files that we are creating while the conversion is in process (like they are checking the files in the directory or some such). This causes random failures on groups of files where then is more than one oggenc2 running concurrently. The workaround for now is to go back to the old encoder or limit the conversions to one at a time.

In passing, is it a known problem that if MC is terminated in the middle of a sync that the portable device will sync from scratch (= delete every file, or files are all reported as "delete on sync", then proceeds to sync every file back to the device) from then on? It seems like during this period of time when I was using the updated encoders my handheld library was inconsistent and that I had to delete all the music on my device and the JRInfo and JRState XML files in the root of my device. Should I open a separate thread for this?

Yes

[lowjoel]

Thanks Bob.

I've used the Rarewares aoTuV encoder again last night and left JRiver to sync overnight. I woke up this morning to find my system completely frozen (even the logon screen didn't show up after the monitor went to standby). Checking the transcoded files folder showed that the sync stopped roughly 1 hour into the sync. I'll try to see if reducing it to 1 encode will work; thanks for the suggestion.

Perhaps we could report this to the RareWares' admins? (I can't find a link to anyone, except David Naylor but he doesn't seem to have anything to do with the site, save designing the templates.

[bob]

Thanks Bob.

I've used the Rarewares aoTuV encoder again last night and left JRiver to sync overnight. I woke up this morning to find my system completely frozen (even the logon screen didn't show up after the monitor went to standby). Checking the transcoded files folder showed that the sync stopped roughly 1 hour into the sync. I'll try to see if reducing it to 1 encode will work; thanks for the suggestion.

The freeze is weird. It doesn't fail that way here. It sounds more like a sleep problem to me.

Perhaps we could report this to the RareWares' admins? (I can't find a link to anyone, except David Naylor but he doesn't seem to have anything to do with the site, save designing the templates.

Yeah, it would be good to report it so someone. I don't know where the problem is though. It could be in the oggenc or in the vorbis libs..

[Alex B]

Perhaps we could report this to the RareWares' admins? (I can't find a link to anyone, except David Naylor but he doesn't seem to have anything to do with the site, save designing the templates.

Rarewares is only a repository. If you suspect an oggenc problem you could post a report to Hydrogen Audio forums: http://www.hydrogenaudio.org/forums/index.php?showforum=57

[lowjoel]

The freeze is weird. It doesn't fail that way here. It sounds more like a sleep problem to me. Yeah, it would be good to report it so someone. I don't know where the problem is though. It could be in the oggenc or in the vorbis libs..

My computer does not go to standby, it merely switches the monitor off. But the whole OS seems to have deadlocked in that scenario.

Could I confirm:

There's a bug in the rarewares ogg encoders in that they independently open the temporary files that we are creating while the conversion is in process (like they are checking the files in the directory or some such). This causes random failures on groups of files where then is more than one oggenc2 running concurrently. The workaround for now is to go back to the old encoder or limit the conversions to one at a time.

• So there is a problem either with oggenc2 or libvorbis.
• But JRiver's stock encoder using libvorbis works.
• And JRiver uses oggenc2.
• Assuming JRiver uses stock libvorbis and stock oggenc2, then the problem would have to lie with RareWares' builds, not so much in the libraries themselves.

Please point out if I'm missing something. I don't think that I'm sufficiently informed about audio technology (and how it interacts with the rest of the computer) to be reporting this bug to HA. I'm definitely not sure about the nitty gritties of MC, either.

[bob]

My computer does not go to standby, it merely switches the monitor off. But the whole OS seems to have deadlocked in that scenario.

I don't have a lot of ideas as to what could be going on there.
Maybe try minimizing MC before walking away.
Try turning on MC logging and see if anything interesting shows up in the logs.

Could I confirm:

• So there is a problem either with oggenc2 or libvorbis.
• But JRiver's stock encoder using libvorbis works.
• And JRiver uses oggenc2.
• Assuming JRiver uses stock libvorbis and stock oggenc2, then the problem would have to lie with RareWares' builds, not so much in the libraries themselves.

Please point out if I'm missing something. I don't think that I'm sufficiently informed about audio technology (and how it interacts with the rest of the computer) to be reporting this bug to HA. I'm definitely not sure about the nitty gritties of MC, either.

I signed up for HA and will put it on there when I get a chance. We were using an older stripped down version if the encoder without the plugin support. It could be that is where the problem is.
The encoder opens files we already have open for no apparent reason resulting in a busy file when we try to copy the tempfile.
Reducing it to a single encode at a time prevents the second (or more) instance from messing up what's going on.

[bob]

Ugh, the old encoder has the same problem though it seems to happen less frequently.
For now, The number of concurrent encodes should be set to 1.

[lowjoel]

Thanks for your help investigating this Bob.

Incidentally, I notice that the transcode cache doesn't seem to be building properly with the .128. I've synced my device at least twice (including from scratch last night due to the disrupted sync thing causing some sort of corruption somewhere), and while approximately 2000 files were synced with my phone my transcode cache only has < 10 tracks. Granted that I did use 2 parallel conversions last night...