FreshnessCheck not updating content

Ah, so depending on what opus2tonie.py put in the audio-id I have to turn this off. Thanks.

No, if you disable it, you won’t be able to place older files (audio-id) onto your server. TeddyCloud won’t mark them as updated any more.

I don’t understand. First you said if it’s enabled it will only mark content to be updated if the audio id is newer. Now you’re saying if it’s disabled I won’t be able to place older files on the server anymore?

Sorry, the second enabled should have been disabled.

Idk, there is something else wrong, I think. The server seems to be confused about the files:
INFO |handler_cloud.c:0637:handleCloudFreshnessCheck| uid: E0040350129C5EAD, nocloud: 1, live: 0, updated: 0, audioid: 65B3AFE8 (2024-01-26 13:13:12), audioid-server: 65B3AFE8 (2024-01-26 13:13:12)
but

ls -lah 129C5EAD/500304E0                                                                                                                                                                                                                                       
-rw-r--r-- 1 default default 5.8M Jan 29 11:52 129C5EAD/500304E0

No, the server is not confused about the file. The datetime of the file is not the audio-id (which is also a timestamp). It is within the TAF.

But this file was just generated using the cloud audio encoder…

What is the audio id within the webinterface for that file?

I tried again so the current version is:

Index of /129C5EAD/500304E0  
 
Model: 
Audio timestamp: 1/29/2024, 12:18:45 PM, custom (364349845)
Hash: 823ce1596db64ebb6960e6cabd933f7a3774e5f6
Audio Size/Tracks: 2363392/1

and the latest freshness check:
INFO |handler_cloud.c:0637:handleCloudFreshnessCheck| uid: E0040350129C5EAD, nocloud: 1, live: 0, updated: 0, audioid: 65B3AFE8 (2024-01-26 13:13:12), audioid-server: 65B3AFE8 (2024-01-26 13:13:12)

Okay, great. The ID was backwards.

I am fairly certain, that I created these directories in the wrong order to begin with, but the tonies are working. Is there some automatic conversion?

/129C5EAD/500304E0 is not E0040350129C5EAD

E0 04 03 50 12 9C 5E AD → /AD 5E 9C 12/500304E0
E0 04 03 50 AD 5E 9C 12 ← /12 9C 5E AD/500304E0

No, there is no conversion done. The box may create the folders and jsons via the freshnessCheck on the server, thats all

I have no idea what happened here.

ls -lah 129C58C8 C8589C12                                                                                                                                                                                                                                       
129C58C8:
total 54M
drwxr-xr-x   2 default default 4.0K Jan 26 15:23 .
drwxr-xr-x 107 default default 4.0K Jan 29 13:03 ..
-rw-r--r--   1 default default  54M Jan 26 15:23 500304E0
-rw-r--r--   1 default default  189 Jan 26 15:23 500304E0.json

C8589C12:
total 54M
drwxr-xr-x   2 default default 4.0K Jan 26 15:23 .
drwxr-xr-x 107 default default 4.0K Jan 29 13:03 ..
-rw-r--r--   1 default default  54M Jan 26 15:23 500304E0
-rw-r--r--   1 default default  188 Jan 26 15:22 500304E0.json

Okay, I did a test. Picked a new tag. Put it on the box. The box automatically created a directory:

ls D4*                                                                                                                                                                                                                                                          
zsh: no matches found: D4*                                                                                                                                                                                                                                            
ls D4*                                                                                                                                                                                                                                                          
500304E0.json  

Then I manually created the wrong one, uploaded a file to it, used “Assign Unknown” and put the tag on again. Result:

ls -lah 129C58D4 D4589C12                                                                                                                                                                                                                                       
129C58D4:
total 7.2M
drwxr-xr-x   2 default default 4.0K Jan 29 13:38 .
drwxr-xr-x 109 default default 4.0K Jan 29 13:37 ..
-rw-r--r--   1 default default 7.2M Jan 29 13:38 500304E0
-rw-r--r--   1 default default  189 Jan 29 13:38 500304E0.json

D4589C12:
total 7.2M
drwxr-xr-x   2 default default 4.0K Jan 29 13:38 .
drwxr-xr-x 109 default default 4.0K Jan 29 13:37 ..
-rw-r--r--   1 default default 7.2M Jan 29 13:38 500304E0
-rw-r--r--   1 default default  268 Jan 29 13:37 500304E0.json

So, these files are definitely getting copied to the right location. And then they stay in the wrong one and updating them there gets very confusing.

If you are using assign unknown, the content you selected will be copied to the next empty tag you put onto the box. That is only the case because of the assign unknown and no hidden mechanism.

Not sure what people are using this for but it seems like moving the file instead of copying might be a sensible thing.

The idea is to place your content into the library and let teddyCloud assign it onto the tag you want it to by placing it onto the box. In the future we may use symbolic links to do that. Until then, coping the file is the easiest way to do that without bad side effect.

1 Like

Oh, yeah, the library. Is that described somewhere? I was wondering what that toggle does.

(Maybe it would make sense to prevent “Assign Unknown” from the content section, then?)

https://github.com/toniebox-reverse-engineering/teddycloud/issues/123

2 Likes