BDA.ini blank spaces causing "no channels found"

[JimF]

I am not sure whether this relates to problems that others are having, so I will post it separately.

When I have upgraded the software and firmware in HDHomeRun recently, I have often gotten a "no channels found" during the subsequent Digital Channel Scan in GB-PVR. To make a long story short, I have found that something in this process (I am not sure what) is inserting extraneous blank lines in my BDA.ini file, and that is causing the failure.

For example, even though I created it with only one blank line between the sections, it ends up like this:
[SETUP-Main]

[Silicondust HDHomeRun Tuner XXXXXXXX-0]
TUNING_TYPE=ATSC
RECEIVER_ONLY_MODE=1
FILTER_RECEIVER=Silicondust HDHomeRun Tuner XXXXXXXX-0
PIN_RECEIVER_IN=Input0
PIN_RECEIVER_OUT=Output1










[Silicondust HDHomeRun Tuner XXXXXXXX-1]
TUNING_TYPE=ATSC
RECEIVER_ONLY_MODE=1
FILTER_RECEIVER=Silicondust HDHomeRun Tuner XXXXXXXX-1
PIN_RECEIVER_IN=Input0
PIN_RECEIVER_OUT=Output1

This prevents the scan from finding any channels for some reason. At any rate, I simply created the file without any spaces at all, and saved it as a "read only" file, and the problem is solved.

[whurlston]

That actually shouldn't have any effect on whether channels are found or not. Did you just update to the 7/13 beta of the HDHomeRun software? There was an update to the firmware that fixed an issue that would cause no channels to be found on ATSC. I'm not sure if it was only related to the HDHomeRun scan or if it affected other apps though. The issue was introduced in the previous firmware.

From the release notes:

Firmware:
- ATSC: Fix problem where channels were missed in channel scan (problem introduced in last beta release).
- Improvements to signal reporting.

[JimF]

That actually shouldn't have any effect on whether channels are found or not. Did you just update to the 7/13 beta of the HDHomeRun software? There was an update to the firmware that fixed an issue that would cause no channels to be found on ATSC. I'm not sure if it was only related to the HDHomeRun scan or if it affected other apps though. The issue was introduced in the previous firmware.

I am scanning QAM channels only, and updated (starting with the released 20090415 version) to both the 20090703beta2 and the 20090713beta1 versions, and the problem occurred both times. I always use the HDHomeRun ATSC/Remap option, which is the only one that works for me, but in each case tried the ATSC/QAM and GB-PVR options when I couldn't find the channels (doing an HDHR and GB-PVR scan each time), but that did not fix it. All I had to do was replace the BDA.ini file each time, and that worked to fix the GB-PVR scanning problem.

But I have also noticed problem upgrading the HDHR software and firmware, which I have posted in their forum, and may be related to Vista x64, but I don't know how that would affect BDA.ini in any case. In fact, I don't know what would want to write to the BDA.ini file at all.

[whurlston]

The HDHomeRun Setup adds the appropriate entries to the bda.ini depending on the setup you used. I haven't used/tested ATSC/Remap since 1.3.11 has been released.

When scanning QAM with GBPVR and the HDHomeRun (not using ATSC/Remap), you should be scanning the offset frequencies instead of channel numbers. If you scan channel numbers, the HDHomeRun will add a 1.75MHz offset to the default frequency which can result in no channels found. Did you ever use the QAM.ini manager when scanning in GBPVR? It's not needed with the latest HDHomeRun software though as it will create a custom qam.ini

[JimF]

The HDHomeRun Setup adds the appropriate entries to the bda.ini depending on the setup you used.

OK, I think I see the problem. I was creating the BDA.ini manually (the old way), but somewhere along the line, probably when I tried the GB-PVR option in HDHR, it inserted its own information and created some conflict in the file.

At any rate, I deleted my BDA.ini file, and allowed HDHR to scan with the GB-PVR option, which created a new BDA.ini that works now. Also, I used the new 20090714beta1, which may have corrected something that contributed to the problem in the first place.

Thanks for the input.