Issue Number | 4473 |
---|---|
Summary | Audio Import Fails |
Created | 2018-05-14 14:48:08 |
Issue Type | Bug |
Submitted By | Englisch, Volker (NIH/NCI) [C] |
Assigned To | Kline, Bob (NIH/NCI) [C] |
Status | Closed |
Resolved | 2018-05-18 17:01:52 |
Resolution | Fixed |
Path | /home/bkline/backups/jira/ocecdr/issue.226028 |
We identified a bug that prevents new audio files from being imported to the CDR. This problem likely started with our Gauss release on Feb 15th.
~oseipokuw, since the audio import isn't working correctly at this time please stop importing any audio files until the problem has been fixed.
Adding my explanation of the problem I've sent to Bob:
From: Englisch, Volker (NIH/NCI) [C]
Sent: Monday, May 14, 2018 1:10 PM
To: Bob Kline <bkline@rksystems.com>
Subject: Hawking Bug?
Hi Bob,
I need your help scratching my head. We’ve published two DrugInfoSummaries on Friday which finished publishing on GK
with a warning. The warning is that the audio files which were newly created last week didn’t exist. It looks to me
that the audio files do exist and in fact the vendor output includes these files but they haven’t been pushed to GK.
These are the two DIS:
- CDR792116 – audio file CDR793342
- CDR792335 – audio file CDR793333
All four files have been created for the vendor output but only the DIS have been pushed to GK even though the audio files
have a publishable version created before the weekend publishing job started.
There is no entry in the doc_blob_usage table for the two audio files but I’m not certain about the function of that table.
I don’t see any errors in the logs that I’ve looked at so far.
Since the audio files are brand new they should have been part of the publishing job on Monday when they were made
publishable but didn’t get included. That seems to be the reason for the GK publishing warning.
Would you be able to take a look at the publishing software to identify if new audio files are handled properly or
can you tell me where to start digging?
Since Feb. 15th, the release of Gauss, there have only been two ZIP files loaded, one of which was a revision to the main file.
Week_126.zip (loaded from SFTP server: 2018-03-30)
Week_126_Rev1.zip (loaded from SFTP server: 2018-04-05)
~oseipokuw, Blair told me that the missing audio files are currently preventing the DIS documents from being published. Is it possible to remove the audio links and publish the documents without until the fix is in place?
Let's see if we can't get the missing audio files in place today. That part we can do without enlisting CBIIT's help. Getting the audio import interface to work correctly will require CBIIT's assistance. We just have those two Media documents to fix to get the broken DIS publishing back on the road, right? I can use those two for testing my script to restore the blobs.
Yes, as far as I can tell only those two media documents were reported missing on GK.
Can one of tell me how we ended up dealing with DIS documents linking to the audio files, when the audio import program is linking GlossaryTermName documents to the Media documents?
I have new publishable versions for CDR0000793342 and CDR0000793333, with blobs attached. Once you have confirmed that the blobs are correctly saved, I will take care of the other audio files.
I'm still hoping for an answer to the question in my previous comment.
I was in a meeting and we had a fire drill.
As for the link between the DIS and the audio file, the DIS is linking to the glossary term which is linking to the media document, so the DIS is listing the same pronunciation audio file as the glossary term does.
Would you like me to run a hot-fix of the media files to confirm everything is working or did you have something else in mind?
I was thinking of having one of you bring the documents up in XMetaL, and then click the "Launch Media File" icon on the toolbar, confirming that the right audio file got attached to the document. Of course, I suppose you'll eventually need to do the hotfix/re-push magic to get past the other bug of the broken media diff (OCECDR-4474).
Yes, I can play the file from XMetaL and it sounds like it's the correct pronunciation file.
Shall I do the rest?
Let me first try to push the documents to GK with a hot-fix.
You mean just those two, right?
Did you assign it back to me because you're ready for me to save the remaining missing blobs?
No, I marked the ticket to 'In progress' which automatically assigned it to me, so I fixed that re-assignment.
The hot-fix for those 2 documents finished and I was able to reprocess the DIS documents on GK without the warning.
I assume that implies "Yes" as the answer to my question above ("shall I do the rest?"). Done. Here are the CDR IDs to be pasted in for a hotfix job:
CDR0000793317 CDR0000793302 CDR0000793330 CDR0000793322 CDR0000793325 CDR0000793338 CDR0000793296 CDR0000793311 CDR0000793328 CDR0000793293 CDR0000793306 CDR0000793308 CDR0000793319 CDR0000793332 CDR0000793294 CDR0000793341 CDR0000793313 CDR0000793323 CDR0000793336 CDR0000793314 CDR0000793305 CDR0000793316 CDR0000793300 CDR0000793290 CDR0000793339 CDR0000793299 CDR0000793310 CDR0000793292 CDR0000793309 CDR0000793329 CDR0000793331 CDR0000793321 CDR0000793324 CDR0000793326 CDR0000793318 CDR0000793315 CDR0000793304 CDR0000793337 CDR0000793297 CDR0000793301 CDR0000793291 CDR0000793303 CDR0000793340 CDR0000793327 CDR0000793298 CDR0000793334 CDR0000793307 CDR0000793320 CDR0000793295 CDR0000793312 CDR0000793335
I'll let the Nightly Job do it's thing first. If these aren't picked up automatically I can run a hot-fix after.
The nightly job appears to have pushed the audio files. You probably want to spot-check some of the glossary terms to make sure they have their pronunciation clips, ~oseipokuw.
I have a patch to correct the original problem, which I have applied to QA. I don't want to install it on DEV yet and have you test it there, because other changes have been made to DEV as part of the work on Ising, so we wouldn't be testing in an environment which mirrors PROD, as QA does. Please test the audio import script on QA, ~oseipokuw, and make sure that as part of that testing you verify that the blobs for the audio files actually get saved with the Media documents.
I guess this isn't as "Critical" as I thought. The part that really was urgent (saving the missing blobs for the most recent audio import job) has been taken care of.
I am able to verify that the blobs were saved with the audio files with 2 documents that were not already processed on QA.
Thanks. Please test on STAGE and if that's successful I'll have CBIIT promote the patch to PROD.
Verified on STAGE. Thanks!
The patch is on PROD. Future imports should succeed. Ticket can be closed.
Verified on PROD. Thanks!
File Name | Posted | User |
---|---|---|
screenshot-1.png | 2018-05-17 17:46:51 | Kline, Bob (NIH/NCI) [C] |
Elapsed: 0:00:00.220813