Odd problem with Network Encoder

[wnjj]

Have you tried setting seeker/fast_mux_switch=false on the main server?

[panteragstk]

Originally Posted by wnjj

Have you tried setting seeker/fast_mux_switch=false on the main server?

I tried that setting and the first test it seems to have solved the problem.

Thanks, but I still feel like there is another issue of some sort. What else can I provide to troubleshoot this one?

[wnjj]

Originally Posted by panteragstk

I tried that setting and the first test it seems to have solved the problem.

Thanks, but I still feel like there is another issue of some sort. What else can I provide to troubleshoot this one?

I assume you mean the live show transition issue seems to be gone? I expected it might, since the strange file size queries Jeff pointed out are happening when fast_mux_switch simply changes the filename for encoding. Turning that off basically causes a stop/restart for the new file if I'm reading
the code correctly.

I'm still coming up to speed on how this all works but near as I can tell, the tuners are capturing on the windows machine but streaming the data back to a "file" which is actually an "stv://" path on the Linux main server or a network share. What I haven't found is which code processes that stv URL on the server.

The Windows machine MpegMux simply calls a standard Windows library 'CreateFile' with that "stv://" path. The thing is, if it fails the return code is passed back from the mux to the Encoder but is ignored in the switchOutputFile code that calls it. I suspect there's a clue in here as to why the live show fast switch isn't working.

I could be following the code trail wrong, though at there are plenty of options.


So is issue #1 in your original post (seemingly shared channel changes) what you're concerned about? Is that still happening?

[panteragstk]

Originally Posted by wnjj

So is issue #1 in your original post (seemingly shared channel changes) what you're concerned about? Is that still happening?

That one appears to be gone. There were duplicate entries in the properties file that had more than one tuning device name. I changed those to what they should be and it seems to have corrected things.

[Narflex]

OK, I'm pretty sure I found the bug now...it's been there forever...apparently not many people used encoding server upload with seamless file switching on Windows....which is somewhat of a surprise.

If you look here:

https://github.com/google/sagetv/blo...2Dump.cpp#L657

That's where the dumper filter that writes out the data is in the mode where it's looking for an MPEG start code where it's a clean boundary to transition from one file to the next. Once it finds it, it writes out what's left up to that point in the current file....then closes the current file and opens the new file and continues writing from there.

The problem lies here:

https://github.com/google/sagetv/blo...Dump.cpp#L1102

When it closes the file...it also sets m_bRemoteFile to FALSE for some reason (likely me just trying to make the state known)...however, m_bRemoteFile has already been set to TRUE in the SetFilename method so now when OpenFile is called, it doesn't realize that it's supposed to be a remote file and tries to open the stv:// directly as a local file and will fail when it does that.

I've just checked in what should be a fix for this...but I can't compile Windows code currently so I have no way to test this.

[panteragstk]

Originally Posted by Narflex

OK, I'm pretty sure I found the bug now...it's been there forever...apparently not many people used encoding server upload with seamless file switching on Windows....which is somewhat of a surprise.

If you look here:

https://github.com/google/sagetv/blo...2Dump.cpp#L657

That's where the dumper filter that writes out the data is in the mode where it's looking for an MPEG start code where it's a clean boundary to transition from one file to the next. Once it finds it, it writes out what's left up to that point in the current file....then closes the current file and opens the new file and continues writing from there.

The problem lies here:

https://github.com/google/sagetv/blo...Dump.cpp#L1102

When it closes the file...it also sets m_bRemoteFile to FALSE for some reason (likely me just trying to make the state known)...however, m_bRemoteFile has already been set to TRUE in the SetFilename method so now when OpenFile is called, it doesn't realize that it's supposed to be a remote file and tries to open the stv:// directly as a local file and will fail when it does that.

I've just checked in what should be a fix for this...but I can't compile Windows code currently so I have no way to test this.

Well then. Who do I have to bribe to get it done?

Or, what would I need to compile the windows code if nobody is willing to do it?

[KarylFStein]

Originally Posted by panteragstk

Well then. Who do I have to bribe to get it done?

Or, what would I need to compile the windows code if nobody is willing to do it?

There's a sticky on compiling the Windows native code. I have this and the JAR creation set up on my desktop. Granted I don't know what all is going on, but have an EXE based on the latest GitHub entries. Attached in ZIP format.

[wnjj]

Originally Posted by KarylFStein

There's a sticky on compiling the Windows native code. I have this and the JAR creation set up on my desktop. Granted I don't know what all is going on, but have an EXE based on the latest GitHub entries. Attached in ZIP format.

The fix Jeff made is to MPEG2Dump.ax.

[KarylFStein]

Originally Posted by wnjj

The fix Jeff made is to MPEG2Dump.ax.

Of course! Where does that .ax file go? One of the DLLs? Here's the whole build directory minus the .ax files due to space.

[wnjj]

Originally Posted by KarylFStein

Of course! Where does that .ax file go? One of the DLLs? Here's the whole build directory minus the .ax files due to space.

What I meant is the fix affects MPEG2Dump.ax. Doesn't the build create MPEG2Dump.ax? If it combines with other source and compiles into another file I'm not sure which one. Just post that one file for the patch.

AX files are like DLL's (dynamic loaded binaries) but are specifically for DShow filters.

[KarylFStein]

Originally Posted by wnjj

What I meant is the fix affects MPEG2Dump.ax. Doesn't the build create MPEG2Dump.ax? If it combines with other source and compiles into another file I'm not sure which one. Just post that one file for the patch.

AX files are like DLL's (dynamic loaded binaries) but are specifically for DShow filters.

Sure, it's attached. There are no .ax files in my production SageTV folder, though.

[jusjoken]

Originally Posted by KarylFStein

Sure, it's attached. There are no .ax files in my production SageTV folder, though.

I do not have a PC in front of me but try up a level in the Common folder

k

[wnjj]

Like jusjoken said, it's in SageTV/Common instead of SageTV/SageTV.

Thanks for compiling, KarylFStein.

panteragstk, give that new .ax file a shot with seeker/fast_mux_switch=true.

[panteragstk]

Originally Posted by wnjj

Like jusjoken said, it's in SageTV/Common instead of SageTV/SageTV.

Thanks for compiling, KarylFStein.

panteragstk, give that new .ax file a shot with seeker/fast_mux_switch=true.

Thanks for trying, but no workie. I'm still impressed with how this community is so helpful. You guys rock...except that it doesn't work yet

[wnjj]

Originally Posted by panteragstk

Thanks for trying, but no workie. I'm still impressed with how this community is so helpful. You guys rock...except that it doesn't work yet

You replaced the MPEG2Dump.ax in the Common directory on the encoding server? That's surprising that it didn't fix it.

I love a good puzzle. If you want to post the main and encoder server logs again with this new ax file in place I'd take another look.

[panteragstk]

Originally Posted by wnjj

You replaced the MPEG2Dump.ax in the Common directory on the encoding server? That's surprising that it didn't fix it.

I love a good puzzle. If you want to post the main and encoder server logs again with this new ax file in place I'd take another look.

Yeah. I'm surprised as well. Puzzles are fun, but this one is frustrating because there seems to be little to go on. I'll post logs when I get a chance.

[wnjj]

Originally Posted by panteragstk

Yeah. I'm surprised as well. Puzzles are fun, but this one is frustrating because there seems to be little to go on. I'll post logs when I get a chance.

Sorry if this is insulting but I assume you restarted Sage on the encoder server after replacing the filter file?

[Tiki]

Originally Posted by wnjj

Sorry if this is insulting but I assume you restarted Sage on the encoder server after replacing the filter file?

Also, don't .ax files need to be registered like .dll files in Windows?

[wnjj]

Originally Posted by Tiki

Also, don't .ax files need to be registered like .dll files in Windows?

Yes, but from what I can tell, you don't need to re-register if you are replacing one with a compatible interface. They are loaded into memory so you would have to restart the app and maybe Windows itself (doubtful)?

[panteragstk]

Originally Posted by wnjj

Sorry if this is insulting but I assume you restarted Sage on the encoder server after replacing the filter file?

Originally Posted by wnjj

Yes, but from what I can tell, you don't need to re-register if you are replacing one with a compatible interface. They are loaded into memory so you would have to restart the app and maybe Windows itself (doubtful)?

Yup. Restarted sage. It still gives an error, but the recording doesn't die like it did. It will eventually continue.

I'll restart the encoding server and re-test and attach the logs.