A Few Issues

[secludedhusky]

I'm extremely, extremely happy with the current state of the project. Everything is now functional, something that I am extremely happy with and have been playing around with for the past 5 days.

I do have a few bug reports I'd like to mention. The first bug report is that the HD Radio Album Art sending python example is nonfunctional. I'd like the ability to be able to pipe in album art from an URL, and I wasn't able to get the software to send a 200x200 JPEG or PNG that was saved to the folder containing all the other AAS info AFTER the transmitter was started. It would just output a massive error with a bunch of binary, something that'd be impossible for me to screenshot unless there was an absolute need for screenshotting the entire error.

Something else that I've noticed when running gr-nrsc5 24/7 for the past 4-5 days is that the HD Radio metadata eventually crashes out and stops working around the 24 hour mark of the transmitter running. It won't allow anymore metadata updates and will refuse any additional artist or title submitted to the network sockets.

Another issue is that there is some weird behavior with the PTYs on certain receivers. On NRSC5, it decodes my station with the correct PTYs as seen in the attachment below.

However, when locking the station on a Sangean HDR-14, PTYs simply display as "[No PTY]" on the receiver. I'm nearly certain that I've figured out where the problem resides in the code, however due to unfamiliarity with python bindings (I know how to implement it in C++, just not in the adjacent Python bindings). See

gr-nrsc5/lib/l2_encoder_impl.cc

Line 221 in 92e56c0

/*program_type*/ 0);

line 221 of the lib/l2_encoder_impl.cc. This line sets the value for the Program Type variable that the HDR-14 specifically uses to 0 or "UNDEFINED". The HDR-14 is a few of the only portable receivers that allow you to view PTYs and not setting them both in the SIS and in the L2 Encoder can cause them not to be picked up by the HDR-14, as well as some car radios. Setting the PTY for each subchannel in the L2 encoder, similar to what I implemented in the past with the following code snippet:

         if (p == 0) {
            pty = 26;
          } else if (p == 1) {
            pty = 8;
          } else if (p == 2) {
            pty = 10;
          } else if (p == 3) {
            pty = 27;
          } else if (p == 4) {
            pty = 9;
          }

          write_hef(out_program + 14 + len_locators(nop), first_prog + p, /*access*/ 0, /*program_type*/ pty);

Would allow the HDR-14 to be able to decode program types. I'm unsure exactly how to implement this in the current version because without having decent python experience, I'm not able to adequately test and implement this feature myself. I tried making the L2 encoder have the same blocks as the SIS encoder, but had no luck due to the python bindings not matching up.

Hopefully you can fix the issue with the PTYs by implementing it into the L2 encoder alongside the already implemented program types in the SIS encoder.

Thank you for continuing this project. Wish you the best.

[argilo]

The first bug report is that the HD Radio Album Art sending python example is nonfunctional. [...] It would just output a massive error with a bunch of binary, [...]

The example works for me, and for another person who tested it. Could you cut & paste the relevant parts of the error message you're seeing?

the HD Radio metadata eventually crashes out and stops working around the 24 hour mark of the transmitter running

I can't immediately think of a reason why this would happen. Can you provide any more details on the symptoms? Does the TCP port still accept input?

PTYs simply display as "[No PTY]" on the receiver.

This should be fixed by c13100c. There was no need to add extra parameters to the block, since the Layer 2 encoder already receives program type information from the SIS & SIG encoder block in the SIG packet.

[secludedhusky]

The album art I have since gotten to work after some changes in my code. It does have some issues with corruption, but I think I'm sending it to the TCP port too quickly before it is fully written to disk.

In terms of the HD Radio metadata no longer working around 24 hours, the issue is that after exactly 12 hours 0 minutes and 0 seconds, the TCP port stops accepting input for the metadata commands, despite my script sending it to it detecting that the metadata is connected. After this 12 hour mark, the TCP port stops accepting input and acts normal in my script, but doesn't actually register anything to the program.

In terms of the issues with the PTYs, they have since been fixed and that was a rather fast fix for this project. Thank you a lot.

[argilo]

after exactly 12 hours 0 minutes and 0 seconds, the TCP port stops accepting input for the metadata commands

To be clear, you're talking about the artist / title / lot commands, right? Have you seen the failure at precisely 12 hours multiple times now?

That it fails after precisely 12 hours is an interesting clue, but I still haven't thought of a reason why that might happen. Perhaps I'll add some additional debug logging to the blocks to help with diagnosis.

[secludedhusky]

Yep. I am talking about the artist, title and lot commands. To be exact, the album art also ceases working after the 12 hour mark. This has happened at least 2 times, if not 3 times, since I have started using this newer version of gr-nrsc5.

It might be an issue with the TCP PDU on gnuradio, if it is determined to be an issue with gnuradio, one of us might have to go and post an issue on their repo. But, it might be an issue with configuration or gr-nrsc5, so I don't think we can rule it to gnuradio entirely just yet.

[secludedhusky]

Something else interesting that I noticed from testing around with it is that my MTU is set to 12000 in the TCP PDUs.

Last night, I set it to 10000, the default value, and after exactly 10 hours, the TCP PDU stopped accepting input. I don't know whether this is our problem or what, but I appear to have figured out something.

I'm unsure if the No Delay option is significant either, I haven't played around with it.

[secludedhusky]

After extensive testing and playing around over the past week I have patched the issue myself, or what I feel as if has patched the issue. I have been going strong with album art and radio text for around 24 hours now. I have detailed what I did to fix it in my pull request which can be found here that fixes the issue. #32

[secludedhusky]

I will still be doing testing for a few more days just to completely confirm this was the issue and that nothing else was changed on my system during testing to make it have a longer delay. I will write back here in 24-48 hours if the script is still working.

[secludedhusky]

Testing has finished, issue was resolved with my pull request.

[argilo]

As far as I can tell, all issues reported here have now been fixed, so I'll close off this issue. Let me know if I've missed anything.