Useless git logs

[jedix 0]

I recently started evaluating the options to stream my home movies and pictures to my phone.  I came across a few solutions and started evaluating the pros/cons.  The free version of emby seemed competitive until the Android app failed to stream my movies but as an open source believer, I decided to dig into the code and fix the issue.

 

I forked the project, found, tested, and created a pull request complete with a description of the why this change is needed.  I received a prompt response asking to look at the dev branch instead of master.  I went away to do that but when I came back, the pull request was updated stating that it's not necessary as my fix was included in a release.

 

Okay, thanks?  But the fix is incomplete on the dev branch since it still fails to stream to my client.  I found yet another issue which still doesn't fix the isssue, but at least ffmpeg doesn't fail.

 

I pulled the dev branch again to look for the fix, but it's not listed in the git log.  I found it in a commit with the description 'revert buffer size' which includes my fix for MTS ffmpeg options and includes other code that has absolutely nothing to do with a buffer size.

 

Calling this open source development almost seems like an abuse of the words at this point.  The android code is sealed up, the server code build steps are out of date and broken.. you may as well obfuscate your code, there are nagging messages in the web and android app.  When a developer tries to help the project, fixes are sucked into whatever the next commit happens to be with no indication in the logs.  I'm sorry to say that In the end I dropped almost twice the money on a competing solution that isn't open source.

 

I'm not looking to start a fight or upset people about this solution, I'm just letting you know my experience in hopes that you can fix the community engagement and experience for users and potential developers.

[Luke 42077]

Hi @@jedix, I apologize for getting off on the wrong foot. Hopefully as you can see here we work very hard supporting our users. The reason I asked for logging information is that although I do not doubt that you're having an issue, I didn't think it was related to the -mts input format specifier.

 

I am guessing it is probably related to the IsAvc check that we have been loosening up on and I'll tell you the reason. Although it does prevent stream copy in situation where it shouldn't be used, it also prevents stream copy in situations where we do want it used, and this leads to users complaining about transcoding. Instead we are moving towards the direction of trying to play in the most desirable way possible, then detecting a failure in the video player and falling back to a full transcode. The next releases of pretty much all of the apps will have this, and some have already rolled it out.

[jedix 0]

Thank you for the apology.  The -f MTS specifier to ffmpeg was certainly an issue and the only issue in 3.2.8.15 and  I had included the error message in my commit log.

 

Yes, it is the IsAvc check that's now causing part of the issue for sure.  If I return false, the ffmpeg encoder log is the same as it was in the 3.2.8.15 with the patch I submitted, however the android app now fails to play (black screen with controls but no play button, just pause) and I have no idea why as I have no view into the android player.  I gave up at this point since it's very difficult to follow what logical changes have been made between 3.2.8.15 and 3.2.9.2 as the commit logs are not accurate.