As far as question number 2 is concerned.... When a receiver is flashed, it sets the dvr a certian way. The "timeshift" function is on by default. That is why you see the change in the function of the info button. To change that, go to the DVR settings and turn that feature off. Then it don't make any difference weather a stick or drive is plugged in or not. The info screen will be back to "normal".
I'll try the timeshift OFF and see how that does. I've never gone into the record or PVR area of the receiver before so it should be fun.
That said, the editor has been around since 2007 so to me it is no suprise there are discrepencies.
I didn't report possible format issues, I'm just concerned there may be with the editor so old and the receiver so new. It's hard to think in about 4 years there haven't been some tweaks to the internal receiver database format to add fields for new sat technologies (i.e. DisEQc but that's probably been around long enough to have been planned for in the receiver channel database).
May I ask what the importance of the codec info?
I think it's important to know at a glance what the feed may be using and I like how the Opensat has the info about video codec used, audio codec used, and resolution right there at the first press of the INFO button.
There was a sat feed the other night that was like S80/Q65 and it was artifacty as heck! I was trying to figure out what its deal was but couldn't find that out from the Manhattan because that level of detail is missing from the OSD info screens. I had to lock the signal with my transport stream analyzer to find out the stuff I wanted to know (video stream format and resolution especially) and in the end I was able to determine the feed was bitstarved and thus why it looked so bad. I could have saved about 5 minutes of labor and analysis and having to get out of the comfy chair if the info was available with just a keypress or two in the manhattan.
It might also help with future troubleshooting if you knew the codecs and video resolutions involved to come up with a prediction on when to expect a certain possible bug to show up.
BTW, I think the occasional blind scan find but can't tune issue might have been fixed. I did a blind scan using version 3.3 on one of the unpublished flawed signals. The blind scan wrote it to memory at 1 MHz above the center frequency of that full transponder wide signal and I don't think it's an accident. I think it was programmed in 3.3 that anything on the speculated flawed 4,060 MHz freq on C-band will be written to memory as 4,061 MHz. Right after the blind scan ended, the signal locked and displayed just fine and I didn't manually have to do the workaround trick.