I think he was mistaken in changing this to a string. Looking up the infooptions_t struct for BitRate in Video/Audio/Text streams in MediaInfoLib src it shows they are actually defined as floats, not ints. MediaInfoLib may have returned some float string in certain esoteric formats (ex 1.0, or even 1.) which when used with Int32.TryParse would fail. Just my guess as to the reason for this sudden change.
If we wanted the string representation of a stream there is the BitRate/String property. The plain BitRate property should definitely return some sort of integer (even if its floating point) to do something useful with the info. Strings aren't good for much other than printing.
Channel(s) is also definitely defined as integer, not a string (or float). If MediaInfoLib is returning a non-string value, sounds like a bug in MediaInfoLib. If we need the channels returned as a string there is always "Channel(s)/String". Wonder which esoteric format is returning a non-integer for channels though...
Merge branch 'master' of https://github.com/Nicholi/MediaInfoDotNet
Fix for finding path when using library from ASP.NET. All libraries get shadow copies into a temp dir, so you lose the fact that the dlls are copied to the /bin dir in an ASP.NET site. When ASP.NET loads it has not EntryAssembly it is called from a manager, so Assembly.GetEntryAssembly() == null should be true in all ASP.NET sites and cases like this (loaded from another application). We pull path from AppDomain.CurrentDomain.RelativeSearchPath, else proceed normally for typical desktop applications using GetExecutingAssembly.