Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

copy_number of EFLR items #19

Open
the-mysh opened this issue Feb 9, 2024 · 0 comments
Open

copy_number of EFLR items #19

the-mysh opened this issue Feb 9, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@the-mysh
Copy link
Collaborator

the-mysh commented Feb 9, 2024

Each EFLRItem has an attribute copy_number. It is meant to distinguish between two EFLR items of the same type and name.

The copy_number is computed automatically at the level of an EFLRItem by checking how many EFLRItem instances of the given name are already defined in the parent EFLRSet and subtracting 1 (so for the first ELFRItem of the given type and name, copy_number is 0).

However, this is only checked at the level of the parent EFLRSet of the given EFLRItem. In most cases this is sufficient, because normally a single EFLRSet of a given type is defined in a file, but it is possible to define more (see this issue). In case multiple EFLRSets are added to the same file, it is likely that multiple EFLRItem instances will share the same type, name, and copy_number, making them indistinguishable in DLIS references. As a result, references might point to the wrong items (resulting i.e. in a FrameItem displaying the wrong channel data).

@the-mysh the-mysh added the bug Something isn't working label Feb 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant