Announcement

Collapse
No announcement yet.

Dolby releases Closed Caption hotfix for IMS3000 version 3.5.13

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dolby releases Closed Caption hotfix for IMS3000 version 3.5.13

    Dolby has released a hotfix intended for Dolby IMS3000 Software 3.5.13. There is an issue where the Closed Caption engine crashes on CPLs containing more than 4075 lines. The content can still be played, but closed captioning will not function. This issue was discovered with the QFC-QFC version of the Oppenheimer feature and may affect other packages. With this hotfix, the Closed Caption engine was improved to allow more memory to be used, which should eliminate the line constraints. Dolby recommends updating proactively to this hotfix if you have Software 3.5.13.

    The hotfix is posted in Dolby's customer portal in the 3.5.13 section.

    Mike @ Dolby​

  • #2
    Thanks Mike! Based on the description (apparently a limit on the size of the timed text XML files that could be handled), it SEEMS like this issue only affected the internal parsing of captions (like CaptiView) and would not affect external captioning systems relying on ST 430-10. I'm only guessing, but is that indeed the case?

    Thanks!

    Harold

    Comment


    • #3
      If the total timed text assets being pulled into the RPL exceeded 4075 lines, the closed caption engine in the IMS3000 would crash and become unavailable. This means that any device looking for an RPL wouldn't get one and thus no captions would be available to external devices.

      Mike

      Comment


      • #4
        Thanks for the quick response! 4075 lines IS pretty big for an RPL. I agree, if the RPL cannot be created by the server (from either the show playlist and CPL or just the CPL depending on whether it is an RPL per show or per composition), internal or external captions would not work. Do you know how many bytes are in the RPL?

        Comment


        • #5
          Has it been established for definite that this bug only affects the IMS3000 and that we don't have to worry about patching earlier "DolReMi" models?

          Comment


          • #6
            Seems like an example of sloppy low-bid programming.

            Why would you allocate a fixed-length buffer for a variable-length file like that? Either set it up as a linked list or if memory is that tight just read a line or fifty at a time and do it again as required. The rpl file is sequential and it isn't going anywhere so it can always be (re)read.

            I don't hold myself out to be a professional programmer of any kind and even I can see that...

            Comment


            • #7
              Harold, I don't know the answer to your question.

              Leo, this only affects IMS3000 running 3.5.1x. It doesn't affect other Dolby or Doremi servers, and it doesn't affect IMS3000 with 3.4.

              Mike

              Comment


              • #8
                Mike, thanks for checking!

                Comment


                • #9
                  Thanks Mike.

                  Incidentally, I replaced a backplane in a Barco that had a cat745 IMB in it this morning, and after doing so and checking that test patterns looked OK, verified that DCP playback was good by playing the first 30 minutes or so of Oppenheimer (the reason for the backplane replacement was that the customer had been complaining of random "flashing lines" on the screen, and a process of elimination ruled out the light engine, ICP, and IMB as the cause). The server was a DSS220 on version 4.9.5.2. When I selected the CPL, the transport window alternated between "decrypting subtitles" and "selecting" for much longer than I've ever seen it do that before with an SMPTE DCP that has encrypted timed text: about 3-4 minutes in total. But after that, the movie played OK, including the closed captions (AccessLink and Captiview). Just to be sure that there were no gremlins in the booth, I jumped to the last few minutes before the credits, and the CCAPs were still there.

                  An image then entered my head of Robert Oppenheimer in his bunker at Los Alamos, pushing the big red button and then seeing "Transport not available - error connecting to nuclear device" on a screen...

                  Comment


                  • #10
                    Leo, what you describe reminds me of flushing logs on different circumstances. It could be that reseating the IMB would force a spring-cleaning on subtitles decrypted as well. (Or could it?)
                    I am glad IMS3000 gets prompt support on encrypted timed text. I have a (rather unusual) subtitle-not-showing case on an IMS1000, but bugs can not be squashed without development.

                    Comment

                    Working...
                    X