While receiving SPI, the program blocks

[Peterdoo]

Hello Jan.

While receiving the following MUXes, the program blocks somehow. It is still advancing and displaying the time played, however it stops playing audio. GUI does not react anymore. I assume that processing of one of the received XML files (SI or PI) ends in an endless loop. Just play the following raw recordings and it will happen after about 140 seconds.

https://mega.nz/file/rdMw0ICS#7KdQ09YRPK211-UDhNPwAV5rRDNcQxeopYC5E5cjfss
https://mega.nz/file/mNkk3IwC#XhA8erRI00kFKdtWlhN0ldvemlgo5KMiGMl_YOAMojM

Best regards,
Peter

[JvanKatwijk]

Thanks Here - on Linux - it halts after 275.7 seconds regardless of buttersizes The error (or phenomenon) happens when reading the file both as a "raw" file or as an "xml" file (which it is). What happens is that the buffer is full and the driver wauts for bufferspace, but that does nto come I'm lookig into it Best regards jan Op za 21 feb 2026 om 15:09 schreef Peterdoo ***@***.***>:

…

*Peterdoo* created an issue (JvanKatwijk/qt-dab#388) <#388> Hello Jan. While receiving the following MUXes, the program blocks somehow. It is still advancing and displaying the time played, however it stops playing audio. GUI does not react anymore. I assume that processing of one of the received XML files (SI or PI) ends in an endless loop. Just play the following raw recordings and it will happen after about 140 seconds. https://mega.nz/file/rdMw0ICS#7KdQ09YRPK211-UDhNPwAV5rRDNcQxeopYC5E5cjfss https://mega.nz/file/mNkk3IwC#XhA8erRI00kFKdtWlhN0ldvemlgo5KMiGMl_YOAMojM Best regards, Peter — Reply to this email directly, view it on GitHub <#388>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQGFGDZ2JKNK2K7BY534NBRILAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43ASLTON2WKOZTHE3TEMBZGU2TINA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Jan van Katwijk

[JvanKatwijk]

Found the bug In the dataProcessor in casing packet type 3 for (uint16_t i = 0; i < udlen * 8; i ++) series [i] = vec [3 * 8 + i]; if (series. size () > 0) The loop was runiing endlessly since in the original code the loop variable was declafred as uint8_t udlen was 41, so 5 * 41 > 256 Tonorrow I'll generate a windows version best jan Op za 21 feb 2026 om 19:22 schreef jan van katwijk ***@***.***>:

…

Thanks Here - on Linux - it halts after 275.7 seconds regardless of buttersizes The error (or phenomenon) happens when reading the file both as a "raw" file or as an "xml" file (which it is). What happens is that the buffer is full and the driver wauts for bufferspace, but that does nto come I'm lookig into it Best regards jan Op za 21 feb 2026 om 15:09 schreef Peterdoo ***@***.***>: > *Peterdoo* created an issue (JvanKatwijk/qt-dab#388) > <#388> > > Hello Jan. > > While receiving the following MUXes, the program blocks somehow. It is > still advancing and displaying the time played, however it stops playing > audio. GUI does not react anymore. I assume that processing of one of the > received XML files (SI or PI) ends in an endless loop. Just play the > following raw recordings and it will happen after about 140 seconds. > > https://mega.nz/file/rdMw0ICS#7KdQ09YRPK211-UDhNPwAV5rRDNcQxeopYC5E5cjfss > https://mega.nz/file/mNkk3IwC#XhA8erRI00kFKdtWlhN0ldvemlgo5KMiGMl_YOAMojM > > Best regards, > Peter > > — > Reply to this email directly, view it on GitHub > <#388>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCPHQGFGDZ2JKNK2K7BY534NBRILAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43ASLTON2WKOZTHE3TEMBZGU2TINA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > -- Jan van Katwijk

-- Jan van Katwijk

[Peterdoo]

Wow, that was fast. A tricky one. Thank you.

I just found out that in the following MUX only 5 of 8 logos are received. Not even after an hour of waiting. I am not able to see in the code, what could be the reason. The ones that are not loaded are those with transport IDs 0003, 0004, 0008.

https://mega.nz/file/LIcwkbiY#c1u1UVtI7nKwe7bABeu-6mWHf-9ypizXKTkpQyR5j2A

Best regards,
Peter

[JvanKatwijk]

I'll have a look In the meantime I uploaded a fixed version. It is terrific getting all these issues, as mentioned earlier, here in the Netherlands we only have some audo services, so all development and testing of all types of data services is depending on files with recordings I get best jan jan Op za 21 feb 2026 om 23:37 schreef Peterdoo ***@***.***>:

…

*Peterdoo* left a comment (JvanKatwijk/qt-dab#388) <#388 (comment)> Wow, that was fast. A tricky one. Thank you. I just found out that in the following MUX only 5 of 8 logos are received. Not even after an hour of waiting. I am not able to see in the code, what could be the reason. The ones that are not loaded are those with transport IDs 0003, 0004, 0008. https://mega.nz/file/LIcwkbiY#c1u1UVtI7nKwe7bABeu-6mWHf-9ypizXKTkpQyR5j2A Best regards, Peter — Reply to this email directly, view it on GitHub <#388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQCBNTXK3TIRBT374B34NDM2DAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZZGYZDANJVGQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

[JvanKatwijk]

A minor problem is that I cannot download the file, at a random point it stops and waiting for an hour does not help best jan Op za 21 feb 2026 om 23:37 schreef Peterdoo ***@***.***>:

…

*Peterdoo* left a comment (JvanKatwijk/qt-dab#388) <#388 (comment)> Wow, that was fast. A tricky one. Thank you. I just found out that in the following MUX only 5 of 8 logos are received. Not even after an hour of waiting. I am not able to see in the code, what could be the reason. The ones that are not loaded are those with transport IDs 0003, 0004, 0008. https://mega.nz/file/LIcwkbiY#c1u1UVtI7nKwe7bABeu-6mWHf-9ypizXKTkpQyR5j2A Best regards, Peter — Reply to this email directly, view it on GitHub <#388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQCBNTXK3TIRBT374B34NDM2DAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZZGYZDANJVGQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

[JvanKatwijk]

In the attached file I only see type 4 mot objects in the EPG process (This evening loading the file succeeded) best jan Op za 21 feb 2026 om 23:37 schreef Peterdoo ***@***.***>:

…

*Peterdoo* left a comment (JvanKatwijk/qt-dab#388) <#388 (comment)> Wow, that was fast. A tricky one. Thank you. I just found out that in the following MUX only 5 of 8 logos are received. Not even after an hour of waiting. I am not able to see in the code, what could be the reason. The ones that are not loaded are those with transport IDs 0003, 0004, 0008. https://mega.nz/file/LIcwkbiY#c1u1UVtI7nKwe7bABeu-6mWHf-9ypizXKTkpQyR5j2A Best regards, Peter — Reply to this email directly, view it on GitHub <#388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQCBNTXK3TIRBT374B34NDM2DAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZZGYZDANJVGQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

[Peterdoo]

Type 6 should be there as well. It is transmitted about every 3 minutes only as they have very large PNGs and only 8 kbit/s.

It however only has one segment. Maybe that is the problem. In mot-handler.cpp there is:

case 6:
	      if (segmentNumber == 0) { 	// MOT directory
...
	      }
	      else {
	         if ((theDirectory == nullptr) || 
...
	      }
	      break;

It will enter here when all segments of the object have been received. I don't understand the reason for if else here. All type 6 objects which only have one segment go into if. All type 6 objects which have more than one segment go into else. Complete object wilth all segments is present in both cases. Maybe that is why you don't see the type 6 object.

The same is the case in "case 3:" a little bit above in the code.

Best regards,
Peter

[JvanKatwijk]

Maybe, but the recording only contained type 4 components. I added a print statement to print the type and it was just a single long list of type 4 May be another part of the transmission - not part of the recording - showed other types as well I can add a print statement such that you can monitor the types Just let me know best jan Op zo 22 feb 2026 om 22:12 schreef Peterdoo ***@***.***>:

…

*Peterdoo* left a comment (JvanKatwijk/qt-dab#388) <#388 (comment)> Type 6 should be there as well. It is transmitted about every 3 minutes only as they have very large PNGs and only 8 kbit/s. It however only has one segment. Maybe that is the problem. In mot-handler.cpp there is: case 6: if (segmentNumber == 0) { // MOT directory ... } else { if ((theDirectory == nullptr) || ... } break; It will enter here when all segments of the object have been received. I don't understand the reason for if else here. All type 6 objects which only have one segment go into if. All type 6 objects which have more than one segment go into else. Complete object wilth all segments is present in both cases. Maybe that is why you don't see the type 6 object. The same is the case in "case 3:" a little bit above in the code. Best regards, Peter — Reply to this email directly, view it on GitHub <#388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQCUEBCYSFDGXPVN6YT4NILVLAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBRG4YTONJYHA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

[JvanKatwijk]

Here is a link to a special version https://www.dropbox.com/scl/fi/1tea2zwdd8wlerpb041zn/setup-qt-dab64-6.10-scalar.exe?rlkey=g66dxrmg045ry5mvzfj2z6ebu&dl=0 I rerouted the trace to the MOT handler and - when set - the types of the mot components are printed (trace button is the black one at the right hand side of the second row of buttons on the config window) Hope this helps best jan Op ma 23 feb 2026 om 14:54 schreef jan van katwijk ***@***.***>:

…

Maybe, but the recording only contained type 4 components. I added a print statement to print the type and it was just a single long list of type 4 May be another part of the transmission - not part of the recording - showed other types as well I can add a print statement such that you can monitor the types Just let me know best jan Op zo 22 feb 2026 om 22:12 schreef Peterdoo ***@***.***>: > *Peterdoo* left a comment (JvanKatwijk/qt-dab#388) > <#388 (comment)> > > Type 6 should be there as well. It is transmitted about every 3 minutes > only as they have very large PNGs and only 8 kbit/s. > > It however only has one segment. Maybe that is the problem. In > mot-handler.cpp there is: > > case 6: > if (segmentNumber == 0) { // MOT directory > ... > } > else { > if ((theDirectory == nullptr) || > ... > } > break; > > > It will enter here when all segments of the object have been received. I > don't understand the reason for if else here. All type 6 objects which only > have one segment go into if. All type 6 objects which have more than one > segment go into else. Complete object wilth all segments is present in both > cases. Maybe that is why you don't see the type 6 object. > > The same is the case in "case 3:" a little bit above in the code. > > Best regards, > Peter > > — > Reply to this email directly, view it on GitHub > <#388 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCPHQCUEBCYSFDGXPVN6YT4NILVLAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBRG4YTONJYHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- Jan van Katwijk

-- Jan van Katwijk

[Peterdoo]

I have tried this special version. It displays grouptype 6 after about 53 seconds. The whole recording is more than 6 minutes. So you should be able to see it.

The one grouptype 4 immediatelly following the MOT directory is the one that carries SI. However it is normally not converted to list.xml. But after running more times the same recording, sometimes it also writes list.xml.

It seems to be a bit aleatory. Maybe some uninitialized variable? Maybe it depends whether one is listening at the same time to a service? Maybe SlideShow uses the same TransportIDs and somehow interfers?

Best regards,
Peter

[JvanKatwijk]

Under Windows I can see the type 6 component at 53 seconds, unfortunately under Linux is does not show, so I have some homework best jan Op ma 23 feb 2026 om 20:07 schreef Peterdoo ***@***.***>:

…

*Peterdoo* left a comment (JvanKatwijk/qt-dab#388) <#388 (comment)> I have tried this special version. It displays grouptype 6 after about 53 seconds. The whole recording is more than 6 minutes. So you should be able to see it. The one grouptype 4 immediatelly following the MOT directory is the one that carries SI. However it is normally not converted to list.xml. But after running more times the same recording, sometimes it also writes list.xml. It seems to be a bit aleatory. Maybe some uninitialized variable? Maybe it depends whether one is listening at the same time to a service? Maybe SlideShow uses the same TransportIDs and somehow interfers? Best regards, Peter — Reply to this email directly, view it on GitHub <#388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQABO3UXH5EPVRU6H6T4NNFYHAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBWG4ZTSOJWGQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

[JvanKatwijk]

Selecting a different ofdm decoder solved the problem in Linux. The protection of the station logos was with a coderate 3/4, telling 4 softbits resulting in 3 hrd bits, and that with lots of puncturing. It was a good test for the decoder qiuality (but it took some time before I understood) Anyway, I get the sequence of a type 6 with lots of type 4 components. I printed the continuation index and there were no gaps whatsoever. Of course I got a few logos. Reading the lists.xml file (relevant part attached) shows that for 8 logos descriptions are given, 4 for RNE and 4 for radio 5. Since the lists file does not contain more descriptions, it seems that this is all there is <serviceInformation creationTime="2024-12-4T04:13" originator="AVT MAGIC DABMUX"> <ensemble Eid="effe" ecc="e2"> <mediumName>MF1 MAD</mediumName> <shortName/> <service> <mediumName>Radio 1</mediumName> <shortName>Radio 1</shortName> <bearer id="e2:effe:effa"/> </service> <service> <mediumName>RADIO 5</mediumName> <shortName>RADIO 5</shortName> <bearer id="e2:effe:effb"/> </service> <service> <mediumName>COPE DIGITAL</mediumName> <shortName>COPE DIG</shortName> <bearer id="e2:effe:effc"/> </service> <service> <mediumName>IntereconomiaDAB</mediumName> <shortName>InterDAB</shortName> <bearer id="e2:effe:effd"/> </service> <service> <mediumName>RADIO MARCA</mediumName> <shortName>R MARCA</shortName> <bearer id="e2:effe:effe"/> </service> <service> <mediumName>El Mundo Radio</mediumName> <shortName>El Mundo</shortName> <bearer id="e2:effe:efff"/> </service> <service> <mediumName>RNE DAB+ </mediumName> <shortName>RNE </shortName> <bearer id="e2:effe:efe6"/> <mediaDescription> <multimedia type="logo_colour_square" url="e2_efe6_32x32_0.png"/> </mediaDescription> <mediaDescription> <multimedia type="logo_colour_rectangle" url="e2_efe6_112x32_1.png"/> </mediaDescription> <mediaDescription> <multimedia height="0" type="logo unrestricted" url="e2_efe6_128x128_2.png" width="0"/> </mediaDescription> <mediaDescription> <multimedia height="0" type="logo unrestricted" url="e2_efe6_320x240_3.png" width="257"/> </mediaDescription> </service> <service> <mediumName>Radio 5 DAB+ </mediumName> <shortName>Radio 5</shortName> <bearer id="e2:effe:efe7"/> <mediaDescription> <multimedia type="logo_colour_square" url="e2_efe7_32x32_0.png"/> </mediaDescription> <mediaDescription> <multimedia type="logo_colour_rectangle" url="e2_efe7_112x32_1.png"/> </mediaDescription> <mediaDescription> <multimedia height="0" type="logo unrestricted" url="e2_efe7_128x128_2.png" width="0"/> </mediaDescription> <mediaDescription> <multimedia height="0" type="logo unrestricted" url="e2_efe7_320x240_3.png" width="257"/> </mediaDescription> </service> </ensemble> </serviceInformation> best jan Op di 24 feb 2026 om 09:57 schreef jan van katwijk ***@***.***>:

…

Under Windows I can see the type 6 component at 53 seconds, unfortunately under Linux is does not show, so I have some homework best jan Op ma 23 feb 2026 om 20:07 schreef Peterdoo ***@***.***>: > *Peterdoo* left a comment (JvanKatwijk/qt-dab#388) > <#388 (comment)> > > I have tried this special version. It displays grouptype 6 after about 53 > seconds. The whole recording is more than 6 minutes. So you should be able > to see it. > > The one grouptype 4 immediatelly following the MOT directory is the one > that carries SI. However it is normally not converted to list.xml. But > after running more times the same recording, sometimes it also writes > list.xml. > > It seems to be a bit aleatory. Maybe some uninitialized variable? Maybe > it depends whether one is listening at the same time to a service? Maybe > SlideShow uses the same TransportIDs and somehow interfers? > > Best regards, > Peter > > — > Reply to this email directly, view it on GitHub > <#388 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCPHQABO3UXH5EPVRU6H6T4NNFYHAVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBWG4ZTSOJWGQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- Jan van Katwijk

-- Jan van Katwijk

[Peterdoo]

Nice that you were able to locate the problem cause. Have you changed anything for Windows as well?

Because under Windows from the 9 objects that are there (8 logos + 1 list.xml), very often I only see some of them being received. The signal quality is almost perfect, so there should not be any errors.

I delete the cache folder. Then I start playing the recorded file. After about 4 minutes I cannot see all the 9 objects in the cache folder. It does not happen always. Sometimes it picks all 9, sometimes not. As I said, maybe it depends whether one of the two channels that have logos is selected for listening while waiting for logos.

[JvanKatwijk]

No I did not adapt - or checked - windows yet. I know the signal quality is excellent, but the encoding of the logo data makes that decoding is rather difficult What I said, 4 softbits for 3 hardbits with lots of puncturing I run later on this afternoon the same code - with the same detector - in Windows and monitor the results. As said, in Linux I printed the CI's and in the whole 3 minutes between the two occurrences of the type 6 element there was one or two discontinuities in the CI sequence I'll report on the result best jan Op di 24 feb 2026 om 13:59 schreef Peterdoo ***@***.***>:

…

*Peterdoo* left a comment (JvanKatwijk/qt-dab#388) <#388 (comment)> Nice that you were able to locate the problem cause. Have you changed anything for Windows as well? Because under Windows from the 9 objects that are there (8 logos + 1 list.xml), very often I only see some of them being received. The signal quality is almost perfect, so there should not be any errors. I delete the cache folder. Then I start playing the recorded file. After about 4 minutes I cannot see all the 9 objects in the cache folder. It does not happen always. Sometimes it picks all 9, sometimes not. As I said, maybe it depends whether one of the two channels that have logos is selected for listening while waiting for logos. — Reply to this email directly, view it on GitHub <#388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQBB7PGJCGY6GOZ4XS34NRDK7AVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNJRGYYTENRWHE> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

[JvanKatwijk]

Peter I created - and uploaded - a new version, one wirh minor changes compared to the previous one. I tested with the channel 9D file and different decoders Decoders 1 and 4 give - each run - all 8 + 1 files. Tomorrow I'll look into the decoders. As you mentioned, the signal is excellent and looking at the constellation diagram one would expect that "hard" decoding would be possible here as well. But most likely, the puncturing is a little too much. I'll try tomorrow other deconvolution implementations, just to see what happens, with the less functioning decoders Tonight I m out best regards jan Op di 24 feb 2026 om 14:22 schreef jan van katwijk ***@***.***>:

…

No I did not adapt - or checked - windows yet. I know the signal quality is excellent, but the encoding of the logo data makes that decoding is rather difficult What I said, 4 softbits for 3 hardbits with lots of puncturing I run later on this afternoon the same code - with the same detector - in Windows and monitor the results. As said, in Linux I printed the CI's and in the whole 3 minutes between the two occurrences of the type 6 element there was one or two discontinuities in the CI sequence I'll report on the result best jan Op di 24 feb 2026 om 13:59 schreef Peterdoo ***@***.***>: > *Peterdoo* left a comment (JvanKatwijk/qt-dab#388) > <#388 (comment)> > > Nice that you were able to locate the problem cause. Have you changed > anything for Windows as well? > > Because under Windows from the 9 objects that are there (8 logos + 1 > list.xml), very often I only see some of them being received. The signal > quality is almost perfect, so there should not be any errors. > > I delete the cache folder. Then I start playing the recorded file. After > about 4 minutes I cannot see all the 9 objects in the cache folder. It does > not happen always. Sometimes it picks all 9, sometimes not. As I said, > maybe it depends whether one of the two channels that have logos is > selected for listening while waiting for logos. > > — > Reply to this email directly, view it on GitHub > <#388 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCPHQBB7PGJCGY6GOZ4XS34NRDK7AVCNFSM6AAAAACV3K2BC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNJRGYYTENRWHE> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- Jan van Katwijk

-- Jan van Katwijk