problem loading .bam and .bai files with non-matching names

[trstickland]

[Note: this was observed in Apollo, but I believe it is related to jBrowse]

I encountered a problem trying to load a BAM file, as the index file has a subtly different name:
K173.sorted.markdup.bam
K173.sorted.bam.bai

Obviously this defies normal convention, but the real difficulty was that no data was loaded, and there was no feedback in the UI -- nothing even in the browser console to give a hint of the problem.

It would be great if it was possible to load files without requiring the names to be identical, but pragmatically it would be OK if the end user were notified clearly that it was not being done.

[trstickland]

Apologies, should have specified I am using the "Open track file or URL" feature, and providing URLs for the BAM file and index file

[garrettjstevens]

Hi, can you confirm something for me? When you add the BAM/BAI, after providing the URLs, does anything display in the "New Tracks" box at the bottom before you click "Open," or does it still say "None"?

I think what's happening is that the open button isn't adding any tracks at all, which is why you're not getting any feedback on the file not loading. Ideally I think it would be good to disable the "Open" button until there are valid tracks to be added.

Also, JBrowse does support arbitrary BAI names, but I'm not sure how to get those to work using the "Open track file or URL" dialog.

[cmdcolin]

It does struggle in this case where the index file doesn't match the specific naming covention we expect, which is:

file.bam
file.bam.bai

There is not really an "override" to this in the file opener.

We could disable the Open button as that does seem confusing but it is sort of difficult in the current paradigm to add files like this.

[trstickland]

@garrettjstevens the 'new tracks' box just says "none"; as a new user I hadn't associated the appearance of something in the new tracks as a prerequisite -- it's obvious in retrospect, but there's quite a lot of elements in that dialog and the sequential workflow isn't immediately obvious.

Deactivating the 'open' button would work, though inactive control it can be confusing -- maybe also add a tip on mouseover indicating what the user needs to do before they can click 'open'?

@cmdcolin if it's difficult, then I don't think it's necessary to enable "inappropriately" named files to be opened -- as a workaround (and goven decent network & disk space!) a user could download and rename files. It would be a big help though if a message could be displayed indicating that the file names are the problem...

Thanks for the quick response :)