ADD Cut behavior is not as expected

[ermina]

Hi,
i just witnessed this on my test 4.1.3 machine, but the issue was already there in 3.5.0.

In a CART that already has multiple cuts, adding a cut will assign an index that "fill holes" instead of incrementing based on the highest cut id present in the cart.
So basically if i have 342 cuts and for some reason i deleted cut 178, adding a cut will not give me an empty cut 343 at the end of the list (expected behavior), but re-create an empty cut 178 in the middle of it (un-intuitive behavior).

Imho, most people's assumption when you ADD an element to a list, is that it is added at the end of the list.
If i record in a cart and then tell a coworker to edit the latest recording i made, they wouldn't have the slightest idea how to find the right cut.

In 2.5.1 the behavior is as expected. This breaks our workflow and i'm a bit surprised that no one complained about that.

[ermina]

it seems to me that the method RDCart::GetNextFreeCut() in lib/rdcart.cpp is where this happens (https://github.com/ElvishArtisan/rivendell/blob/da58e6f355a4528ca28127cf892825529ce4ad0c/lib/rdcart.cpp#L2301C1-L2324C1)

I did some archeology and apparently this changed between 2.5.0 and 2.6.0, so i understand a bit more how everyone is accustomed to the current behavior.

I don't mind reverting the change and maintaining my own local version of RD4. Only question is, if i do that, will there be unwanted side effects ? My gut feeling tells me that it should be ok. I already manually manage carts that approach the 999 cuts limit.

[KeepEmGoing]

You would be able to find the latest recording IF the cut sorting still worked in this version but it does not. You could sort for the ingest date but unfortunately, no sorting works.

[ElvishArtisan]

See #940 for the current discussion about bringing back 'sortability' to the cut list. This will likely happen in the not-too-distant future.

[ermina]

ok. Caveat, when we tried RD3, sorting cuts by date ("origin" field) was useless (as in RD2) because of the US date format (MM/DD/YY), it gave all carts from october, november, december, with january mixed in between, then feb, march etc. regardless of the year. Having cuts originating from different clients also makes stuff worse since the client name is first in this field. Which is why, imho, a single, incremental ID number is the best and most intuitive way.

[ElvishArtisan]

ok. Caveat, when we tried RD3, sorting cuts by date ("origin" field) was useless (as in RD2) because of the US date format (MM/DD/YY), it gave all carts from october, november, december, with january mixed in between, then feb, march etc. regardless of the year.

No question that that original sorting system was a hot mess. Dates should sort by --well-- date, not alphabetically.

Having cuts originating from different clients also makes stuff worse since the client name is first in this field. Which is why, imho, a single, incremental ID number is the best and most intuitive way.

If you're managing multiple clients (advertisers?), then you be much better off using a traffic system and scheduling those in separate carts. The cuts subsystem was never intended to deal with those sorts of situations, and (as you've noted) is missing some of the basic functionality needed to do it properly.