Blog Comments

  1. nads's Avatar

    Quote Originally Posted by starcrytas

    I have these two errors on my recent submission.

    Yep, I get the same

  2. starcrytas's Avatar

    I have these two errors on my recent submission.

  3. ThroughtonsHeir's Avatar

    I'm doing another test... this time I completed the fields correctly and just used "upload and submit"

    the 1st time through... let's see what happens now.

    [edit :this*Now it's the buttons to upload and submit that are greyed out]

    Updated Today at 06:37 PM by ThroughtonsHeir (picture)
  4. ThroughtonsHeir's Avatar



    Simply cannot get the video to be uploaded.
    2.8 gig (3.02gb on disk)
    fopr a 53 minute video of the elements

    ThanksJace Hall thanked this post
  5. thegamer1185's Avatar

    I know it was addressed elsewhere but I'll bring it over here as well. If the video plays through in full, you can't replay/rewind the video from the video player you must refresh the page. This just happened to me using Chrome on a PC if that is relevant.

    ThanksThroughtonsHeir, Rickster8, Jace Hall thanked this post
  6. Jace Hall's Avatar

    Quote Originally Posted by Rickster8

    Sooooo I realize this would be addition by subtraction, but any chance we could just go back to using the old uploader and scrap the new one? Bells and whistles mean nothing to me. I'm sure many here would agree. If it works, we are happy... amirite???


    This upgrade is not due to TG, and unfortunately there is nothing to "switch back" to. This is a massive back-end upgrade that was done system-wide by our video hosting service provider. They made the switch over on Jan 19th and have been working to resolve the various issues.

    Agreed that it is a bit inconvenient right now, but I would ask the community for some patience and to keep in mind that in the long run this will result in better service!

    It is all being worked on as I write this.


  7. Rickster8's Avatar

    Sooooo I realize this would be addition by subtraction, but any chance we could just go back to using the old uploader and scrap the new one? Bells and whistles mean nothing to me. I'm sure many here would agree. If it works, we are happy... amirite???

  8. Barthax's Avatar

    Quote Originally Posted by datagod

    Thank you so much for your help! I downloaded and ran that version of MAME, or at least I tried to run it. It is 32 bit code, won't run on my 64 bit machine. I'll just call this an investigative dead end.


    Back then many people still ran the DOS version of MAME and the INPs were often incompatible across versions.

  9. datagod's Avatar

    Thank you so much for your help! I downloaded and ran that version of MAME, or at least I tried to run it. It is 32 bit code, won't run on my 64 bit machine. I'll just call this an investigative dead end.


  10. Barthax's Avatar

    OK, got opportunity. :P Quick dig through the source code & there has been a version since 0.35b9 onwards:

    /* inp header */
    typedef struct {
    char name[9]; /* 8 bytes for game->name + NULL */
    char version[3]; /* byte[0] = 0, byte[1] = version byte[2] = beta_version */
    char reserved[20]; /* for future use, possible store game options? */
    ** INP_HEADER;


    So your INP is likely 0.35b8 or earlier.

  11. Barthax's Avatar

    Hmmmm... speculating I may be biased towards WolfMAME outputs. I've confirmed original MAME up to 0.70 had little header structure and maybe 70u1 introduced the v1 INP headers with decent info. They were definitely in WolfMAME 0.78 (haven't confirmed original MAME). Haven't got opportunity right now to dig further but wanted to post the potential correction to the above.

  12. Barthax's Avatar

    Quote Originally Posted by datagod


    Thanks for the info @Barthax . I am going to guess that this is from Wolfmame106. I'll download that and see if I can achieve playback.


    Nah, that's early times when there was almost no information in the file.


    0.106 has the hexadecimal version number written at byte 0x0A

    00000000 70 61 63 6d 61 6e 00 00 00 57 6a 00 00 00 01 01 |pacman...Wj.....|
    00000010 90 47 48 dc 00 00 00 00 32 27 f0 61 37 27 77 b9 |.GH.....2'.a7'w.|
    00000020 00 00 00 ff 00 00 00 ff 00 00 00 c9 00 00 00 00 |................|
    00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|


  13. datagod's Avatar


    Thanks for the info @Barthax . I am going to guess that this is from Wolfmame106. I'll download that and see if I can achieve playback.

  14. Barthax's Avatar

    There are multiple different versions of INP file types. More modern versions put the INP version information in bytes 0x10 and 0x11 as Major/Minor. In version 3.0 INP, the name of the emulator (not just version) was printed in ASCII (null terminated) beginning at byte 0x20.

    00000000 4d 41 4d 45 49 4e 50 00 94 1e f0 61 00 00 00 00 |MAMEINP....a....|

    00000010 03 00 00 00 70 61 63 6d 61 6e 00 00 00 00 00 00 |....pacman......|

    00000020 4d 41 4d 45 20 30 2e 31 33 37 5b 57 5d 20 28 4d |MAME 0.137[W] (M|

    00000030 61 72 20 31 32 20 32 30 31 30 29 00 00 00 00 00 |ar 12 2010).....|

    00000040 78 9c 03 00 00 00 00 01 |x.......|

    Look through the source for inptport.h for the header structure of different sources to determine the different layouts.

    If the INP file begins with the ROM set (not MAMEINP identifier) then you're looking at v1 INP which (vague memory) has a hex version byte.

    Updated Today at 08:18 AM by Barthax
  15. datagod's Avatar

    No, it was emailed to me. Timestamps are from when I saved it to my computer. I tried opening with a hexeditor and I see DKONG at the top, but not much else. Just a huge file of emptiness. It is a 40MB file.

  16. bensweeneyonbass's Avatar

    hmmmmm - my first question is this: does it have what appears to be a good timestamp on the file as to when it was created? That would likely help us determine how to approach identifying the version used.

  17. Barthax's Avatar
  18. Barthax's Avatar

    Hi Jace,

    Hopefully these will give some insight. I've obfuscated some portions which seem machine-generated just in case & my cookie.

    Pic 1 confirms the exact byte size was accepted by the uploader: 968,577,429 bytes and also seems to be sending the request as a 320 pixel wide & 320-bps video - probably not relevant. Pic 2 is the user-facing error that pops up (same visual for "Upload" and "Upload and Submit" buttons). Pic 3 is the Internal Server Error Response fed back. Pic 4 confirms the TLS 1.3 in use - probably not relevant.


    ThanksJace Hall thanked this post
    Likesnads liked this post
    Updated Today at 03:25 AM by Barthax
  19. admin staff's Avatar

    Hi Adrian

    We are working with our provider to solve this issue. We will update once this is resolved

  20. Mads Nielsen's Avatar

    Ive tried to upload my 45 min gp. Upload stops at 49%. So only 21 min opload. 😕

Page 1 of 56 1231151 ... LastLast
Join us