Ticket #130 (closed bug: invalid)

Opened 12 years ago

Last modified 8 years ago

Cache: Some m_streamFormat values differ after fresh discovering

Reported by: slack Assigned to:
Priority: minor Milestone: FFADO 2.1
Component: Version: FFADO 2.0-beta5.2 (1.999.34)
Keywords: Cc:
The device the bug applies to: Terratec Phase X24


I noticed the following after updating libffado. The cache file in this situation is updated with the new version.

So, just for fun (to test the caching code once more ...) I compared two versions and there were a few differences.

Further investigation gave:

The values are different when the is written for the first time vs. when the cache is written otherwise (e.g. after an update)

File '0000000003050704.xml.1' is written with the same values after every new discovery of the device, file '0000000003050704.xml' is written after deserialization and serialization.

If you compare the two files, there are 4 different m_streamFormat values.

Hope this helps to make libffado a little bit better ;-)

P.S.: If this is not a bug then sorry fow the noise.


cache_differences.tar.gz (13.6 kB) - added by slack on 06/03/08 12:30:01.

Change History

06/03/08 12:30:01 changed by slack

  • attachment cache_differences.tar.gz added.

06/04/08 01:51:43 changed by ppalmers

This is exactly the kind of testing we need. Check it, try to break it. Thanks.

11/22/08 13:47:41 changed by ppalmers

  • milestone changed from FFADO 2.0 to FFADO 2.1.

03/29/12 06:28:01 changed by jwoithe

Does anyone understand what this is about? Is it a real problem?

04/07/12 04:49:42 changed by jwoithe

  • status changed from new to closed.
  • resolution set to invalid.

In the absence of any further comments about this I'll close this as "invalid". I don't know enough about the caching system to allow me to determine whether this is a problem. However, I would have expected that if there was a real issue in the caching system we would have seen many bug reports caused by cache errors. It therefore seems to me that the observation made by the original reporter does not constitute a bug.

If contrary evidence comes to hand this ticket could be reopened.

04/10/12 01:09:16 changed by wagi

I have not the spec at hand but looking at the code, valid values whould be:


Decimal values like 172, 252 or 220 do not really make sense. I also noted, that only sync plugs are showing this behavior. I would bet that someone forgot to initialize a variable in the firmware :)

IIRC, FFADO ignores those values anyway.